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ABSTRACT 


Automated Information Systems (AIS) are Software systems that support 
administrative functions, such as accounting, payroll, finance, personnel, inventory 
control, logistics, and equipment and maintenance scheduling. An ERP system is a type 
of AIS that works to integrate all the different functional business areas of an 
organization. Since the 1990s, a large number of corporations have transitioned from 
legacy proprietary software to an ERP. The companies who have successfully made the 
transition have greatly benefited from the flow of information across the organization that 
is brought about by the ERP’s ability to integrate the multi-dimensional data into a single 
common database. The current AIS environment of the DOD is marked by a lack of 
systems integration. Eike industry, the DOD is looking to combat this environment with 
ERP systems. This thesis intends to document the history of the ERP implementations in 
the DOD. In addition, this thesis will highlight the different approaches each service is 
taking to complete their transitions. The thesis will also compare the plans of the services 
to the plans that successful corporations executed in their transitions to an ERP. By 
comparing the plans of the services to industry’s guidelines on how to correctly 
implement an ERP, this thesis will provide new analysis to aid the DOD in this critical 
endeavor. 
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I. 


INTRODUCTION 


A. BACKGROUND 

During the 1990s, Presidents George H. W. Bush and Bill Clinton recognized that 
the efficiency of government’s business processes and information systems had fallen 
drastically behind the processes and systems that were being used in the private sector. 
To overcome the gap, the heads of state began to push toward the adoption of private 
industries’ business processes and systems via legislation. The first target for 
transformation was the government’s financial management systems. 

In 1990, the Chief Financial Officers (CFO) Act was passed and 24 executive 
branch officials were established and charged with the modernization of the financial 
management systems of the major U.S. Departments. These included the Department of 
Defense (DOD), the Department of Commerce, the Department of Energy, the 
Environmental Protection Agency, the National Science Eoundation, the Nuclear 
Regulatory Commission, etc. The goal of the CEO Act is for the government agencies to 
generate financial statements that resemble the statements produced by private 
companies. 

The CEO Act of 1990 was followed by the Eederal Einancial Management 
Improvement Act of 1996 (EEMIA) which built upon the CEO Act and recommended 
government agencies employ Automated Information Systems (AIS) capable of 
producing reliable, useful, and timely information to improve decision making and 
accurately maintain accountability of government funds down to the transaction level [1]. 
In 1996, all of the agencies addressed by the EEMIA knew that systems capable of 
delivering this type of information could not be found within the government. Thus, they 
turned to the commercial sector’s key technologies to comply with the EEMIA [1]. 

Also passed in 1996 was the Information Technology Management Reform Act 
(ITMRA). The ITMRA resulted in the establishment of a DOD Chief Information 
Officer who was charged with managing the department’s investment’s in information 
technology assets [2]. It is a position that is mirrored in the commercial sector and exists 
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to ensure that all technology purchases are aligned to ensure interoperability and 
contribute to the strategy of the organization. 

It is clear from the wording of the legislation passed and the positions that were 
created in the early to mid 1990s, that the government was looking to industry for 
answers as to how IT would renew its business processes and financial information 
systems. From industry, the answer would come in the form of configurable information 
systems known as Enterprise Resource Planning systems (ERPs). 

B. CURRENT AIS ENVIRONMENT OF THE DOD 

The pressure to renovate the business processes and systems of the DOD brought 
about by legislation is external to the department itself. There is additional internal 
pressure for change coming from the military leadership because of the operational pain 
of using antiquated processes and information systems. 

While the civilian leadership was mainly concerned with accurately tracking 
dollars in the early 1990s, the military leadership was focusing on business processes 
because of the logistical problems they experienced in the first Gulf War. A hallmark of 
that engagement was that the units that were in need of supplies could not get them in a 
timely and efficient manner. The problem with the logistical pipeline did not stem from a 
lack of equipment in the area of operations; rather, the problem resulted from an inability 
to identify and distribute the massive amounts of equipment in a timely manner [3]. 

At the time of the first Gulf War, the trend in commercial logistics was 
streamlining supply chains, however, the DOD was not a part of this trend. Instead, the 
DOD opted for the mass inventory supply methodology which meant that everything that 
might possibly be used was sent into theater. Once there, the processes for getting the 
supplies to those in need were complex within the individual services and there was 
virtually no interoperability between the services. The end result was pallets of unused 
equipment awaiting return to the U.S. at the end of the war. Upon seeing the 
consequences of the mass inventory approach, the Generals in charge coined the phrase 
“iron mountains” to describe the stacked rows of cargo boxes filled with unused 
equipment and supplies. The “iron mountains” and a failure to support troops on the field 
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of battle troubled the DOD leadership. It was decided then that the DOD had to change 
the way it performed Supply Chain Management (SCM). 

The first step in the DOD’s SCM transformation was the identification of the root 
causes of the “iron mountains.” Investigating the causes led to the determination that the 
ineffectiveness of the DOD’s supply chains was the result of two problems: obsolete 
supply chain management policies and outdated information systems that supported those 
policies. Both problems would need to be remedied to move the logistical capabilities of 
the DOD closer to the capabilities of the commercial sector [3]. Adding to the problems 
that needed to be overcome, there was also the civilian leadership’s FFMIA requirement 
that the DOD produce auditable financial records. 

Traditionally, the DOD had looked to in-house programmers to write the code for 

business system software [4]. Yet, by the time the causes of the “iron mountains” were 

defined in the mid 1990s, the environment surrounding the DOD had changed. The 

Federal Acquisition Streamlining Act (1994) and Federal Acquisition Reform Act (1996) 

had been signed by President Clinton. This legislation reduced the amount of oversight 

for contracts with the private sector thereby encouraging outsourcing to the commercial 

sector. Moreover, in the Quadrennial Defense Review of 1997, Clinton’s Secretary of 

Defense (SECDEF) William Cohen directed the DOD to accept the business practices of 

industry to shape the business process changes that needed to take place in the 

department. Due to the fact that approval for the funding for the SCM and financial 

systems transformation projects would have to go through the SECDEE’s office, the 

military leadership took Cohen’s command to heart and went to the private sector to 

explore the options on how the modernization objectives could be met. Industry 

presented two options: develop custom software that meets the requirements or use ERP 

software. The first option was deemed impractical because of cost and the nature of the 

DOD. Developing custom software is a solution that is reserved for organizations 

looking for the competitive advantage that a custom logistics software suite can provide 

[4]. This customization comes with an extraordinarily high price tag and the organization 

that chooses this path should not be one that is adverse to risk and change. The DOD was 

looking to play “catch-up” with industry. Eurthermore, the DOD is a case study in risk 

avoidance and adversity to change [4]. Ultimately, these factors led to the judgment that 
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the second option of contracting for ERP software is the preferred course of action and 
the separate service components (Army, Navy, Air Force and Marine Corps) along with 
Defense Logistics Agency (DLA) went their separate ways on that path. 

Today the DOD is at a midway point on the course toward ERP releases 
throughout the department to include DLA. All of the enterprise systems are at different 
points in the development phase and the DOD as a whole is awaiting the results to see if 
the ERP endeavors will improve or possibly resolve the problems of the current processes 
and systems that continue to plague the organization to date. 

During current operations in Afghanistan and Iraq in support of the Global War 
on Terror, the forces in battle encounter the same difficulty with logistics that their 
predecessors in the first Gulf War faced. Those in need go without while unidentified 
supplies continue to get stockpiled. Logisticians are in an operating environment where 
they support a unified force but they pull equipment from five different sources of 
supply. All sources lack the visibility that is vital for encouraging confidence in the 
system. This lack of confidence leads to continuous re-orders which leads to more 
stockpiling and waste. The inefficiencies of the defense logistics systems remain the 
same because the systems are still in need of a common architecture and common 
processes [5]. Accordingly, the financial accountability these systems produce has not 
changed and the DOD remains noncompliant with the FFMIA. It is the hope of the 
services and DLA that their separate ERPs individually and collectively will resolve the 
existing crisis. 

C. STATEMENT OF REQUIREMENT 

Billions of dollars have been and will continue to be invested in the DOD ERP 
programs [1]. At a time when the U.S. is actively engaged in costly combat operations in 
the Middle East and is in desperate need of updating its aging equipment, the military can 
not afford to have these programs fall short of their stated objectives. More importantly, 
the future logistical capabilities and legislative compliance of the DOD will be 
determined by the success or failure of these initiatives. Thus, it is important that the 
plans that are being executed for the implementation and integration of these ERPs are 
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analyzed thoroughly. This research is a comparative study of the different service’s ERP 
strategies to reveal the similarities and differences of the individual plans. 

1. Research Questions 

To conduct this research, the following questions will be explored: 

• What is an ERP? 

• By industry’s standards, what is the optimal way to implement an ERP? 

• How does an ERP integrate business processes that are not part of the 
standardized software suite? 

• What are the experiences and plans of the individual DOD ERP programs? 

• What are the lessons learned to date that will assist the DOD in achieving 
the joint vision for the ERP programs? 

D. BENEFITS OF THE STUDY 

This research is ongoing while the DOD is still in the early stages of 
implementation as a whole. The purpose of the research is to gain an understanding of 
the decisions that are being made throughout the force to enhance the cooperation among 
the services. To be truly enterprise wide, each of these ERPs are going to have to be 
integrated with one another at some point in the future [5]. If this integration is never 
achieved, then the DOD will have five more non-integrated legacy systems that do not 
contribute to the joint warfighting capability of the force. Thus, it is the goal of this study 
to aid this future integration by revealing the differences between the programs and the 
obstacles to implementation that have to be overcome to make these systems successful. 
Benchmarking the programs against each other and against industry best practices will 
provide the military leadership a reference for making the decisions that will improve the 
likelihood for success. 

E. SCOPE OF THESIS 

The scope of this investigation is to assess how the ERP programs might be able 
to improve the joint capability of the services and where they might fall short. To do this, 
it will focus on bringing together the different works that have been completed on the 
DOD ERPs. It will examine the ERP programs of the Defense Eogistics Agency (DEA), 
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the US Army, Navy, Air Force, and Marine Corps to discover what the programs are 
doing communally and what they are doing individually. 

F. METHODOLOGY 

The thesis will use a literature review and interview methodology to gather 
information about ERP implementations in the private and public sectors. Literature to 
better understand ERP applications in general will be examined to define what an ERP is 
and the potential they have to reduce cost and increase capabilities. Eor the DOD ERP 
programs specifically, a combination of literature reviews and interviews will be 
conducted. 

G. ORGANIZATION OF THE THESIS 

Chapter II will present the history of ERP. It will also cover the potential benefits 
and hazards of an ERP implementation as well as the steps that should be taken to 
migrate from the legacy environment. 

Chapter III provides an overview of the separate DOD ERP programs. A 
synopsis of how each of the programs came about will be given. Additionally, the 
current state and cost of the programs will be explored. 

Chapter IV analyzes the similarities and differences between the differing 
approaches of the separate services and DLA. The results of the study will be drawn 
form this analysis. 

Chapter V concludes the thesis by identifying the barriers that must be overcome 
to make these programs a success. Several recommendations as to how these barriers 
might be overcome will be presented. Lastly, some additional areas of research will be 
opened up. 
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II. ENTERPRISE RESOURCE PLANNING 


A. HISTORY OF ERP 

Proprietary systems that are developed by an organization’s in-house or 
contracted software developers are generally referred to as legacy systems. These 
systems are designed using the overarching principal that whatever business processes 
are done without the use of a computer can be replicated in software. Automating 
processes that were formerly done manually provides a benefit in that it decreases the 
amount of time it takes to complete the same process. Written in high-level 
programming languages such as FORTRAN and COBOL, legacy systems are the first 
stage in the evolutionary history of computers in the workplace [6]. 

The problem with legacy systems is that they are developed to meet particular 
functions. This design philosophy causes fragmentation between the disparate functional 
areas. Systems that support a particular functional area but do not integrate with other 
systems are commonly referred to as “stovepipes” [7]. Since stovepiped systems are 
often in need of the same data, the result is the data is maintained in several different 
locations to service the separate systems. Fragmentation and a lack of integration 
between the disparate systems often result in problems with the consistency of the data 
residing in the different locals. Data may be updated in one system but the change does 
not take effect and is not visible in the other systems that are also maintaining that data. 
The coordination and communication problem that is the consequence of this framework 
is severely detrimental to the organizations that operate in this way because users have to 
take extra time to validate data in order to guarantee the reliability of the information 
being produced from the data [8]. 

ERP grew out of the foundation laid by legacy systems as an answer to the 
problems of non-integrated systems. In the 1970s software engineers began to realize 
that data transcends functional area [8]. Additionally, they began to capitalize on the 
commonalities that existed between the business processes of different manufacturing 
companies independent of the end products that were being produced by those 
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companies. They did this by creating packaged software that was designed to be used in 
any manufacturing environment with little modification. 

1. Materials Requirements Planning 

The predecessor of ERP is known as Material Requirements Planning (MRP). It 
is a software package developed in the 1970s as a simulation tool to answer the questions 
in the universal manufacturing equation. Manufacturing firms operate under the 
principals of the universal manufacturing equation which asks [8]: 

• What are we going to make? 

• What does it take to make it? 

• What do we have? 

• What do we have to get? 

For the companies who elected to purchase an MRP, the logic built into the software uses 
models of available capacity in the manufacturing plant and linear scheduling to produce 
a master schedule which satisfies the “what are we going to make” question. To handle 
the “what does it take to make it” question, MRP uses a bill of materials which details all 
the components that go into whatever is being made. Calculations of lead-times to 
receive those components are in the software for the scheduling of purchase orders that 
must be made to get the components in time for production. This takes care of the “what 
do we have to get” question and the “what do we have” question is resolved with an 
inventory database in the MRP [9]. 

2. Closed-Loop MRP 

After their release, MRPs were quickly altered to closed-loop MRPs with the 
added capability of inputting changes in delivery schedules from the suppliers of sub¬ 
components. With the updated delivery schedules, a closed-loop MRP is capable of 
comparing the new delivery date and the date that the components are required to enter 
production. The comparison highlights the situations where the components are not 
going to arrive as scheduled [10]. Feeding back delivery schedules into the MRP is the 
reason for the loop portion of the new name. The feedback loops which allow the input 
of updates to reflect the reality of the changing supply environment are used by the 
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capacity planning tool that was also upgraded in closed-loop MRPs. Plant scheduling 
functionality was improved so that priorities in production can be modified based upon 
the information that is coming in on the feedback loops. The feedback functionality 
characteristics of closed-loop MRPs are diagramed below. 



Figure 2.1. Closed-Loop MRP System Showing Feedback (From: [11]) 

3. MRP II 

In 1975, MRPs got more improvements and another new name. The name 
changed to Manufacturing Resource Planning with an abbreviated name of MRP II. 
Manufacturing replaced materials as the first word in the new name because the 
advancements with MRP II allow the user to plan all aspects of manufacturing including 
personnel, machines and inventory. The two additional components that provide MRP 
this capability are tools that capture all the cost and sales information of the plant and 
simulation tools that allow the user to change different aspects of the production plan to 
perform “what-if’ analysis that can then be acted upon [12]. 


4. ERP 

During the technology boom of the 1990s, MRP II was expanded beyond 
manufacturing floor by incorporating customer relations modules, human resources 
information, facilities management, and accounting into the common database repository 
of the software. Today’s ERP is an enterprise wide system that integrates all aspects of 
what an organization does and delivers current cross-functional information to every 
department and supply chain member in the organization. 
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Figure 2.2. The ERP Wheel (From: [4]) 


5. ERP II 


The current movement in the world of information technology (IT) is to branch 
out of the enterprise and link the organizational systems to the companies that business is 
conducted with. Using the internet or electronic data interchange (EDI), organizations 
are sharing the data in their central ERP repositories with the trusted companies in the 
supply chain. Not only are companies sharing data, they are also sharing business 
processes and shattering the barriers to information that traditionally existed between 
interacting organizations. This contemporary free-flow of information between 
organizations that are fusing separate enterprise systems is called ERP II [13]. 

Companies that interact in this manner are operating under what is known as the 

“web-like” value chain concept [4]. The hallmark of the concept is that the systems of 

the separate organizations are integrated so that the information held by the systems is 

visible to the employees, customers, suppliers, and trading partners who are held 

responsible for acting on this information. Not only are the systems integrated, but the 

business processes between the organizations are automated. This automation eliminates 

the phones, faxes, and e-mails that have been traditionally used to conduct transactions 
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and chase down the most current information. Instead, all parties involved have total 
access to the updated information about the dynamic events and transactions that are 
occurring within and between the separate organizations. In industry, companies that 
operate in the “web-like” value chain are referred to as real time enterprises because they 
are acting on the most-current information available from their integrated business 
systems [14]. 

B. EXPECTED BENEFITS OF AN ERP 

When an organization successfully implements an ERP, the benefits it can expect 
include [15]: 

1. Cycle time reduction ERP can provide substantial benefits in terms of 
cost and time reduction in key business processes. 

2. Faster information transactions An ERP can deliver a reduction in the 
time to enter pricing information from five days to five minutes. 

3. Better financial management One of the basic functions of ERP systems 
is managing financial information across the enterprise. 

4. Laying the groundwork for e-Commerce Centralized data in an ERP 
system facilitates linkage to e-Commerce systems. 

5. Making tacit process knowledge explicit Key processes, decision rules, 
and information structures are well understood and documented in an ERP 
system. 

These benefits are compounded when an organization becomes a real time enterprise and 
transparency is achieved across all the companies in the supply chain. A quality ERP 
implementation allows every department to know exactly what every other department is 
doing. Adopting ERP II and opening ERPs to the other organizations in the supply chain 
permits every department throughout the separate organizations to know what resources 
are available for use at all times. When a company takes this action it is extending the 
enterprise and the information that is produced results in profitable decision making [16]. 

1. Shortened Timeline 

The expected benefit of having an integrated database that facilitates the 
transparent flow of information throughout an enterprise and between interacting 
enterprises is the primary reason for choosing an ERP system. It is this capability that 
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brings about improved business processes and increased profitability. Yet, there is an 
additional reason for electing ERP in that it shortens the timeline associated with 
software development. 



Requirements Analysis . Testing & Operating 

Definition & Design opmen Implementation & Maint. 


Time 

Figure 2.3. ERP Implementation (From: [4]) 

An ERP is software and because it is, all of the phases of software development 
from requirements definition to operations and maintenance must be gone through to get 
the system up and running. The time it takes go through the phases is abbreviated due to 
the fact that the ERP for each individual organization is developed using a generic 
template that models the way work should be performed in that particular industry. For 
example, if the company performing the implementation is a manufacturing company, the 
manufacturing template will be used. If it is a distribution company, then that template 
will be the starting point. In addition to the templates for the commercial sector there are 
also ERP templates for educational and government institutions. Since the requirements 
of the industry or organization are known and built into the template, the time it takes to 
do analysis and design along with system development can be dramatically shortened 
[17]. 
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C. VENDORS 

Today’s ERP market is divided into two levels of suppliers: large-scale and small- 
scale. Capturing approximately 64 percent of the total ERP market revenue are the three 
large-scale suppliers SAP, Oracle Corporation, and Baan International [4]. The 
remaining 36 percent of the market is spread among the smaller ERP companies that 
produce specialized ERPs for particular industries. 

Eive former IBM employees founded SAP and created the first ERP. As the 
originator of ERP technology, SAP holds the top position among ERP providers and 
controls 30% of the market. Behind SAP is the Oracle Corporation with 24% of the 
market. Oracle has established a high market share because of its advantages in 
scalability and better coordination with suppliers and customers [18]. It also increased its 
market share after performing a hostile takeover of the PeopleSoft Inc. in January of 2005 
[19]. The takeover provided Oracle with the 9% of the ERP market that was previously 
held by PeopleSoft. Companies that concentrate on global operations tend to choose 
BAAN International because of its modules that link the monetary and technological 
requirements of the various countries operated in [18]. 

D. SUCCESS STORIES 

Several of the best run and most successful companies in the world run ERP 
software and those companies that are looking to continue those successes are making the 
transition to being ERP II organizations. It has been reported that over sixty percent of 
U.S. Eortune 1000 companies run an ERP [20]. Many of these companies made the 
transition to an ERP prior to the year 2000 to achieve Y2K compliance. Within the 
companies that elected ERP for Y2K compliance, the decision was made to buy the latest 
packaged software on the market vice trying to fix the Y2K problems residing in their old 
computer systems. It is a good thing that the companies did make the transition because 
by integrating the data throughout the organization, these companies have been able to 
speed up processes, improve communication, and make better decisions. The result is a 
position amongst the U.S. Eortune 1000 companies and more satisfied customers yielding 
bigger profit margins. 
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1 . 


General Electric 


An example of an industrial giant that moved to an ERP in the 1990s is General 
Electric (GE). With roughly 300,000 employees worldwide GE is an industrial behemoth 
that does everything from making jet engines to managing financial portfolios. GE 
implemented an Oracle ERP and received all of the expected benefits from the 
implementation including cycle time reductions, faster information transactions, better 
financial management, and e-Commerce expansion. Eurthermore, when most companies 
were drastically reducing their investments in IT after the bursting of the “dot-com 
bubble” in 2001, GE increased IT spending by twelve percent in 2002. The increase was 
caused by the Chief Executive Officer, Jeff Immelt’s belief that GE needed to move 
beyond ERP to ERP II. The company desires to digitize every business process that 
could be digitized internal and external to the company. It is an initiative that has paid 
off and continues to pay off. Aided by the ERP II initiative, between 2002 and 2006, the 
company’s consolidated revenue grew from $112 to $163 billion [21] and in 2006, GE 
ranked first overall in Eortune Magazine’s “America’s Most Admired Companies” [22]. 

2. The United States Mint and Strategic Petroleum Reserve 

ERP has been proven to work as well in public organizations as it does in private 
entities. In 1998, a bureau of the Department of Treasury, the U.S. Mint implemented an 
SAP ERP system to replace the multiple legacy systems it was running. The Mint is a 
unique public sector organization because it is self-funded and profit-driven. It generates 
profit by selling coins to collectors. Prior to 1998, the legacy systems run in the Mint 
were incapable of properly handling the planning, tracking, inventory and scheduling of 
the raw materials that go into producing coins. Packaging and delivery of the coins 
following production was also inadequate with only half of customer’s orders being 
shipped within eight weeks of purchase [23]. The accuracy and timeliness of financial 
and management information was an issue as well. Problems with the mint’s information 
systems did not end inside the organization. There was no interface to connect the 1.1 
million coin collecting customers to the mint’s IT systems. The only way customers 
could purchase coins was through a mail order catalog or at three retail kiosks [23]. It 
resulted in profits that were well below what they could have been. To fix the problems 
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with the internal processing systems, the ERP was the first thing to be implemented. 
After the ERP was up and running, an on-line retail site was established in 1999 to 
interface to the customers. Both endeavors were a resounding success. In total, the 
projects cost $40 million with a projected seven-year savings of $80 million. 
Additionally, in 1999 revenue increased by 51.9% over 1998 as a result of the popularity 
of the e-commerce site [2]. 

In the same timeframe that the U.S. Mint was migrating from the legacy 
environment to an ERP, another Eederal agency, the Strategic Petroleum Reserve (SPR) 
was also making the switch. Established following the OPEC oil embargo of the 1970s, 
the purpose of the SPR is to store and maintain an inventory of crude oil as a deterrent to 
oil import cutoffs. The SPR also provides an emergency stock of oil in the event that it is 
needed for national defense [24]. 

SAP was selected as the vendor to provide an ERP solution to the SPR in 1997. It 
was determined that the SPR needed to change their information systems because it was 
experiencing the traditional problems that occur with legacy systems. The same data 
existed in numerous locations and the confusion that resulted was hampering mission 
performance. The SAP ERP was up and running in March of 1999 and the eight legacy 
systems of the SPR were turned off. Eike the results at the Mint, the SPR’s ERP was a 
triumph and achieved 98% of the organizational goals that were established at the outset 
of the project [25]. A year after going live on their ERP, the SPR advertised a 47% return 
on the $10 million ERP investment [2]. 

E. CRITICISMS OF ERP 

Along with the proponents and success stories supporting ERP systems, there are 
also many critics and ERP failures. Criticism is not misplaced since the statistics 
covering IT project failure rates are not encouraging. In 1997, the consulting firm KPMG 
questioned Canada’s leading 1,450 public and private sector organizations. The intent of 
the questionnaire published was to figure out the reasons behind the failure of IT projects. 
Over 61% of the projects analyzed in the study were reported as failures [26]. 
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1. The Boston Consulting Group and Robbins-Gioia Surveys 

More recently, two other surveys were conducted specifically addressing ERPs. 
The first of these was completed by the Boston Consulting Group in the year 2000. After 
surveying 100 executives of leading companies about their ERP initiatives, they found 
that only one out of every three executives considered the initiative a success [27]. These 
results were supported by the survey of another consulting firm in 2001. Robbins-Gioia 
EEC conducted the same type of questionnaire survey about the perception of 
organizations with regard to their ERP package implementations. A total of 232 
organizations responded and 36% of the respondents had, or were in the process of 
implementing an ERP. Of the enterprises that had experience with an ERP system [26]: 

• 51% viewed their ERP implementation as unsuccessful. 

• 46% of the participants noted that while their organization had an ERP 
system in place, or was implementing a system, they did not feel their 
organization understood how to use the system to improve the way they 
conduct business. 

• 56% of survey respondents noted their organization has a program 
management office (PMO) in place, and of these respondents, only 36% 
felt their ERP implementation was unsuccessful. 

There is a bias in both of these surveys because they are based upon perceptions 
of the ERPs and they do not take into account if the ERPs cited as unsuccessful achieved 
the goals established. Additionally, if the survey respondents were not part of the 
implementation team and the systems were forced upon them, they are inherently going 
to have a pessimistic view of the ERP [26]. Despite these facts, the surveys are a good 
demonstration of the fact that the odds of success are not stacked in favor of the ERP. 
Thus, ERP project managers must be aware of, and attempt to avoid the pitfalls 
associated with ERP failures. 

2. Pitfalls of ERP Implementations 

With the multitudes of ERP implementations (both successful and unsuccessful) 
occurring over the last two decades, there has been plenty of opportunity to discover and 
define the ERP pitfalls that should be avoided. Prior to going into what those pitfalls are, 
it is important to delineate what constitutes a partial and total ERP failure. Different 
criteria for partial failure include [After: 28]: 
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1. Not making the promised return on investment, 

2. Inordinately extending the implementation schedule and start-up date, 

3. Running over budget by large variances, 

4. Grinding the organization to a crawl pace, or the severest of all 
consequences, 

5. Stopping production and/or not delivering orders to your customers. 

What can be considered a total failure is to invest large sums of money into an ERP only 
to find that the organization is incapable of seeing the project through to completion. 
Thus, the ERP project is terminated and the organization finds itself back at the starting 
point with nothing to show for the resources expended. Such a tragedy is an indication 
that there was not enough research into what would be required of the organization in the 
transition to the ERP environment [8]. 

In order to prevent having a partial failure or a total failure, an organization that is 
planning to adopt an ERP should be made aware of, and expend every effort and all 
resources required to evade the pitfalls and consequences summarized in Table 1. 
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Pitfall 

Definition 

Consequence 

fl.) Overcustomization 

Every organization is unique 
in data requirements and 
business processes. 
Customizations transform 
packaged ERP software into 
ERP software that meets 
organizations' individual 
business processes and 
operations. 

Long and expensive customization efforts 
often result in the pass of release deadlines 
and budget overruns. Customizations may 
make the software more fragile and harder 
to maintain when it finally goes to 
production. 

( 2 .) Lack of Tod Management 
Commitment 

The delegation of the ERP 
project to lower management 
levels. 

Upper management is "out of touch" with 
critical events and the scope of the project. 
This results in a lack of resources being 
committed to the project. 

(3.) Resistance to Chanee/Lack of 
Buv-in 

Lack of a change management 
program. 

A lack of buy-in often results from not 
getting end-users involved in the project 
from the very start, thereby negating their 
authorship and ownership of the new system 
and processes. 

(4.) Inadeauate Reauirements 
Definition 

Not comprehensively and 
systematically developing a 
quality set of functional 
requirements definitions. 

Poor package selection resulting in 
implementation failure. 

(5.) Poor ERP Package Selection 

Inadequate research into 
whether or not the proposed 
system will meet the users 
needs. 

Implementation failure. 

(6.) Inadeauate Resources 

Attempting to save money by 
having the organization's 
employees implement the 

ERP on an overtime basis. 

The organization's employees do not have 
the skills required to implement the software 
and they burn out. 

(7.) Miscalculation of Time and 
Effort 

The miscalculation of effort 
and time it will take to 
accomplish the project. 

ERP project is doomed to failure. 

(8.) Misfit of AoDlication Software 
with Business Processes 

Not examining the business 
processes in the software that 
is going to conflict with the 
business processes of the 
organization. 

A failure to integrate the applications with 
the business processes causes loss of 
productivity and time, and ultimate benefits. 

(9.) Unrealistic Expectation of 
Benefits and ROI 

Software providers are 
notorious for overstating the 
benefits in terms of ROI, 
when the total costs of the 
project have been understated. 

No chance of achieving the anticipated ROI. 
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Pitfall 

Definition 

Consequence 

(10.) Inadequate Trainine and 
Education 

ERP-related training is crucial 
as most employees must learn 
new software interfaces and 
business processes which 
affect the operation of the 
entire enterprise. 

Shortchanging this part of the ERP 
implementation leads to much pain and 
suffering downstream. 

(11.) Poor Project Design and 
Management 

Short-cutting critical events in 
the project plan, such as time 
for documentation, redefining 
and integrating processes, or 
testing before "going live." 

Weaknesses and opportunities for 
improvement are not identified. 

(12.) Poor Communications 

A failure to announce the 
reason for the up and coming 
effort, and not continuing to 
advise the organization of the 
progress and importance of 
the ERP implementation to 
the company. 

Different parts of the organization will not 
able to assess how they will be impacted by 
changes in processes, policies, and 
procedures. 

(13.) Ill-advised Cost Cutting 

Going live at multi-plant sites 
simultaneously or, 
unrealistically compressing 
the schedule in order to save 
on expenses. 

Subjecting all plants or some plants to a 
total shutdown should there be a false start¬ 
up. An overrun of both the schedule and the 
budget. 


Table 1. ERP Pitfalls and Consequences (After: [28, 29]). 


One of the most commonly cited partial failures in history occurred as a result of 
a company’s inability to dodge a pitfall. 


3. Failure at Hershey Foods 

In 1998, the leading manufacturer of chocolates in the United States, Hershey 
Foods attempted to implement an SAP ERP with consequences that cost the company 
tens of millions of dollars. The problem at Hershey involved pitfall number seven: 
miscalculation of time and effort. Believing that the company could push into the final 
stages of implementation during a peak period for business (right before Halloween), the 
company attempted to do both. The truth was that the ERP implementation brought 
about major changes to Hershey’s business processes at a time when the company needed 
to be focusing on its core competency of producing and distributing products. 
Unfortunately, something had to give and in this instance it was the production and 
distribution of products. The result was that for Halloween 1999, the problems with the 
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ERP prevented the delivery of $100 million in candy and Hershey’s stock price fell more 
than 8% in a single day [30]. In the long run, what happened to Hershey was only a 
partial failure. The company recovered from the loss and continues to produce sugary 
treats. Some Wall Street financial analyst even argue that the company does it better now 
with their new system. 

4. The Nestle, Allied Waste and K-Mart Experiences 

Similar to what happened at Hershey, another major chocolate producer. Nestle 
also had significant difficulties with their ERP implementation. After starting an SAP 
ERP implementation in 1997, by 2000 the company was facing a complete collapse. To 
blame for the predicament was pitfall numbers three: resistance to change/lack of buy-in. 
The ERP project team had failed to include the key stakeholders who would be most 
affected by the new business processes and systems. Thus, when the ERP was rolled out 
for use in 2000, the company experienced a major personnel problem. The workers who 
were supposed to use the system had no idea how. Their ignorance was compounded by 
the fact that their superiors could not be of any assistance because they were left out of 
the project as well. Tearing the worst, the company stepped back from the $200 million 
project midway through and took it in a new direction. The new direction was to 
deemphasize the release of software and emphasize management of the change that the 
workers were going to experience with the ERP. Key stakeholders were brought into the 
project team and training on the new system became widespread. Eortunately, the ERP 
team at Nestle had the wisdom to shift the emphasis because by 2002, the company was 
touting a $325 million savings from their ERP. Hindsight being what it is, at the 
conclusion of the ERP, Nestle’s team leader stated that “The primary lesson taken away 
from the project is this: No major software implementation is really about the software. 
It’s about change management” [31]. 

Allied Waste Industries and the retailer K-Mart were not as fortunate with their 
ERPs as Hershey and Nestle. After spending over $40 million on an SAP ERP, Allied 
Waste declared the system too complex, too expensive and a poor fit for the way the 
company does business. It was ruled a total failure and the company wrote-off the $40 
million as a loss [32]. K-Mart also experienced a total failure with their ERP and had to 
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write-off a $130 million loss. Total failures such as these are not as common as partial 
failures, but, they are included as evidence of the worst that can happen if the pitfalls of 
ERP are not thoroughly analyzed and prepared for prior to starting the project. 

F. ERP PAINS 

As organizations world-wide move away from systems developed “in-house” 
toward the packaged software of ERPs, studies have shown that what happened at 
Hershey and Nestle is the norm vice the exception [30]. The cost and publicity of the 
partial failures are usually not as dramatic as those suffered by Hershey, but they are 
almost always present in an ERP undertaking. Commonly, installation of the software is 
late and business processes suffer for approximately six months [30]. These problems 
that have become the standard with ERP implementation account for the negative 
perceptions that were revealed in The Boston Consulting Group and The Robbins-Gioia 
surveys. Of course, there are exceptions to this standard because some organizations can 
never overcome the pitfalls (Allied Waste and K-Mart) and some are extraordinarily 
successful at managing the pitfalls and never experience the pains normally associated 
with ERP. Eor example, the Microsoft Corporation went live with an SAP ERP within 
seven months of the initial planning meetings and immediately captured the benefits of 
the integrated ERP environment [5]. Microsoft is the worldwide leader in computing 
software so familiarity with software driven initiatives certainly came into play. 
Nonetheless, Microsoft credited the success with their ability to control pitfall number 
two: lack of top management commitment. Ultimate responsibility for Microsoft’s ERP 
implementation rested with the Chief Operating Officer [5]. A top official was charged 
with monitoring the implementation schedule and his visibility in this role emphasized 
the importance of the ERP project to everyone in the corporation. 

Instantaneous success with ERP like what was experienced at Microsoft is the 
exception. The foundation of ERPs is that business processes transcend an organization’s 
functional areas. It follows that the design of ERPs is standardized with the best business 
practices and processes built-in to the software. Historically, legacy systems are built 
around the activities of different functional areas. The system used depends upon the 
department that the worker is operating in. If something goes wrong outside of that 
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particular department, it is somebody else’s problem. ERP destroys this mentality 
because the people in the different departments can see all of the same information. 
Thus, the accountability that is required of all the departments is tested in an ERP like 
never before. If a department is not operating as it should be, it is going to immediately 
be visible to all the other departments in the organization. To obtain such visibility and 
business process integration, the organization that adopts an ERP must conform to the 
processes that are resident within the system. This entails an extensive business process 
reengineering effort due to the fact that all new business processes will be put in place. 
Attempting to do it any other way would mean trying to conform the ERP to fit the old 
way of doing business which is leads to pitfall number one: overcustomization. 

1. The Role of Change Management 

Business process reengineering (BPR) of the magnitude required by the 
installation of an ERP mandates that the organization undergo what is often referred to as 
a technochange. The term techno comes before change because it is a change that 
deliberately uses IT to transform an organization. A technochange is different than an IT 
project because in an IT project, the only department involved in the project is the 
information services (IS) department. The extent of an IT project does not go far beyond 
upgrading the current systems or IT infrastructure to achieve better response times and 
performance. A good example of an IT project is the upgrading of servers. While such a 
change would have a big impact on the IS department, it would generally be transparent 
to the system users except for the improved performance the users experience as a result 
of the upgrade. 

Technochange uses IT to alter the organization’s behavior and has an impact far 
beyond the IS department. In a technochange initiative, the organization has elected to 
use technology that mandates a change in business processes. Consequently, the people 
who use the new IT system and the organization as a whole must undergo a radical 
transformation. This type of transformational change using IT requires more than just 
good software developers and programmers who can produce a smooth running product. 
In order to achieve the performance improvements that technochange products (like 
ERPs) advertise, the users of the product must be prepared for a significant divergence 
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from their current processes. It is this requirement that causes the word change to 
encompass the second half of the phrase technochange [33]. 

Change is a broad expression that has several orders of magnitude. There are big 
changes, small changes, changes that take several years and changes that are completed 
in only seconds or nanoseconds. Beyond orders of magnitude, a second characteristic of 
change is that it affects virtually everything. Organizations do not have the capacity to 
escape the grasp of change and accordingly they fall victim to it. The most extreme 
change an organization can go through is known as a transformational change. 
Transformational change requires a drastic reconceptualization of the way work should 
be done by the workers undergoing the transformation [34]. It is the hardest type of 
change because it requires the organization to disregard the past and work toward the 
leadership’s vision of what the organization should look like. Due to the scope of change 
that is brought about by technochange initiatives such as an ERP, it can only be classified 
as a transformational change. Most transformational change efforts fail because of the 
amount of effort they require at all levels of the organization. Technochange endeavors 
are no exception to this rule [33]. This is the reason that the statistics involving worker’s 
perception of ERP initiatives are dramatically pessimistic. Reactions to changes in 
organizational business processes are negative because the changes to the way people 
work in an ERP are drastic. Even when the ERP does what it was designed to do and 
does it well, the pain of the change that is experienced by the organization will have an 
inverse relationship to the cost of the program. However, the relationship is not directly 
inverse; the most pain resulting from the organizational change comes after the majority 
of the spending on the project has taken place. Thus, the real barrier to seeing the project 
through to the point where the net benefits begin to get realized is not a matter of 
economics but a matter of how well the organization can manage the change that is 
taking place. 
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Figure 2.4. BPR: In it for the Long Run? (From: [35]) 

To help the organization through the pain caused by the change takes a mastery of 
pitfalls two (Lack of Top Management Commitment) and three (Resistance to 
Change/Lack of Buy-in). Managing pitfall two is self explanatory: to successfully 
transition to an ERP, the change can not be driven by middle managers. The leadership 
at the highest level of the organization must be convinced that a change is necessary and 
commit to pushing their agenda for change. Once the ERP technochange has been firmly 
established as the leader’s agenda, that leader must begin to foster support/buy-in for the 
ERP. A technique for developing a consortium of supporters for the change is to surface 
a mini crisis which dictates that a change must occur. The BPR life cycle provides a 
clear demonstration of the phases of a technochange initiative with regards to the 
organizational resistance that must be met and overcome. 
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Figure 2.5. BPR Organizational Life Cycle (From: [36]) 

In the beginning of the change, a “strong man” must emerge and create a crisis 
that demands change. For example, at Microsoft, the “strong man” of the ERP initiative 
was the Chief Operating Officer. The crisis that he used to gain support for the decision 
to transition to an ERP was the incredible growth that the company was experiencing in 
2001. A growth that was so impressive that it was straining the financial, operations, and 
human resources systems of the company. ERP was chosen as the solution to the 
problem and it was rapidly implemented [5]. 

In this case, Microsoft chose an authoritarian approach to contend with the BPR 
organizational life cycle. A top leader was selected, a solution was chosen, and the 
technochange was pushed through with little time for opposition. This is one way of 
countering the resistance to change in the “struggle for power” phase of the life cycle. 
Another way of countering resistance is to create buy-in. An approach that has been 
developed and has had proven success at creating buy-in is known as prototyping. This 
approach involves the development of a futuristic model of how the system will work and 
the capabilities that it will bring to bear as a demonstration to the users to get feedback on 
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how the prototype can be refined. The fact that the users also get to work with the system 
and experience its functionality firsthand goes a long way toward instilling a sense of 
ownership at the user level in the change effort. This “grassroots” support can be a 
critical ingredient towards a project’s success. Prototyping does not negate the need for a 
“strong man” but it can be used by the “strong man” as a tool vice having to resort to a 
dictatorship [33]. 

A variation of the prototyping approach is a pilot project. Pilots entail testing an 
organizational redesign in one or two locations. If the redesign proves its value in those 
locations then it can be employed throughout the rest of the organization. Pilot projects 
reduce risk by proposing easy termination if it is determined that the project is not going 
to meet expectations [33]. 

The approach that an organization applies to steer an ERP implementation 
through the BPR organizational life cycle is not as important as the life cycle itself. An 
organization can use prototyping, pilot projects, or an authoritarian approach and they can 
all be equally effective. The important thing is that when it comes to an ERP initiative, 
the life cycle is very real. People do not like change and the organizational change that is 
required by an ERP is going to generate resistance. If the organization does not follow 
the life cycle and counter the resistance with a “strong man”, incremental victories and 
continual improvements, the resistance movement will prevent success. 

2. Cost 

Prior to phase one of the BPR life cycle and the “strong man’s” announcement 
that an ERP project is going to take place, resistance to the project will appear because of 
the cost. With an average total cost of ownership (TCO) for a large ERP in the hundreds 
of millions, making the decision to acquire these systems will significantly affect the 
organization’s bottom line [32]. The TCO includes the cost of the hardware, software, 
professional services and staff, but, along with the TCO, there are also hidden costs that 
potential consumers should be aware of. Many of these hidden costs occur because of a 
failure to manage the ERP pitfalls. Professionals in the ERP industry cite these hidden 
costs as the source of budget overruns. These costs result from [After: 17]: 
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1. Training - Developing a curriculum to train all the people in the 
organization impacted by the ERP was voted the number one 
underestimated budget item. 

2. Integration and testing - Integrating the ERP with the other software 
systems the organization is using and then testing those links can be 
costly. 

3. Customization - Eosing control of pitfall number one and transforming 
the ERP into custom software will definitely overrun the budget. 

4. Data conversion - Moving the data from the legacy systems to the ERP 
comes with a high price tag. 

5. Data analysis - If the data needs in the ERP needs to be combined for 
analysis and data mining, the cost of the tools to do this should be 
projected. 

6. Consultants ad infinitum - Be wary of continually increasing the number 
of consultants to manage the project. The objectives and cost of the 
consultants must be clearly delineated early-on. 

7. Replacing your best and brightest - Employees with earned skills from the 
ERP implementation will be in high demand. Eunds must be available to 
keep these people or replace them with IT workers that have similar .skills. 
Replacing them will cost much more than rewarding them appropriately. 

8. Implementation teams can never stop - The ERP must be continually 
improved upon and rejuvenated as demonstrated in the BPR life cycle. 
Keeping the team together and actively improving the system comes with 
a cost. 

9. Waiting for ROI - The return on an ERP will not be noticeable for a long 
time after implementation. An organization must be financially prepared 
to wait. 

10. Post-ERP Depression - After the ERP goes live, there is going to be a 
drop in organizational performance while people get accustomed to 
working with the new system. 

With such a high TCO and the significant risk of budget overrun from the hidden 
costs, resistance is going to build because there will be those that wonder what the 
justification could possibly be for embarking upon a project that is almost guaranteed to 
overrun the budget and has the potential for being a complete disaster. An ERP can not 
be defended with the argument that it provides a competitive advantage to increase 
revenue. A competitive advantage is provided only by a capability that one organization 
has that competitors can not gain access to. Eor example, Wal-Mart’s IT systems can not 
be classified as legacy because of the huge sums of money that the company spends to 
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keep their systems on the “cutting edge” in SCM processes and speed. The competitive 
advantage of the company resides in those systems. If Wal-Mart were to change over to 
an ERP, they would lose that competitive advantage and they would be on a level playing 
field with every other discount retailer. ERPs are available to every organization willing 
to pay the price so they do not offer a competitive advantage. They are a good choice for 
an organization that does not quite know what it’s processes are and is therefore looking 
for a software package to implement the “best practices” of the ERP. Utilizing the 
software’s processes prevents having to go through an extended systems analysis time 
trying to figure out what the organization’s processes are and then analyzing if those are 
the processes they should be following [4]. In the ERP’s best practices lies the potential 
for improved internal operations. They do not offer competitive advantage but they do 
offer the potential to rise to a level of service that has become the standard. If an 
organization is functioning extremely well without an ERP, then there is no need to buy 
one. However, if an organization finds that they are unable to track customer orders, 
coordinate manufacturing with those orders and is carrying an excessive amount of 
inventory, then an ERP is a good choice [17]. The most successful companies in 
America are using an ERP. A fact that is supported by the following statistics [4]: 

• 7 of 10 Most Profitable 

• 9 of 10 with Highest Market Value 

• 7 of Top 10 Pharmaceutical Companies 

• 7 of Top 10 Computer Companies 

• 7 of Top 10 Petroleum Companies 

• 6 of Top 10 Electronic Companies 

• 8 of Top 10 Chemical Companies 

• 8 of Top 10 Eood Companies 

With these statistics, which delineates who is using an ERP, a company that can not 
compete with the companies that are successfully running an ERP will quickly fall 
behind. 
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3. 


Alternative to ERP 


Thus, the question becomes what is the alternative to an ERP? The only 
alternative to adopting an ERP is to develop custom software and attempt to build-in 
better business practices than what is contained in an ERP. There are several problems 
with this alternative which increases the risk and cost associated with it. A clear fact that 
has already been established is that people do not like change. Consequently, when the 
software development life cycle begins with requirements definition, it is hard to define 
requirements that are a drastic departure from the current business processes. The biggest 
part of requirements definition is asking the users of the current systems what the 
requirements of the new systems should be. Unfortunately, the natural tendency of users 
is to describe the way they currently do their job which leads to the old business 
processes being established as the requirements of the new system. The second problem 
with custom software is the amount of time it takes as compared to an ERP 
implementation. New software does not have the benefit of a template to work from so 
everything is built from ground zero. This substantially increases the analysis and design 
phase and the development phase of the life cycle. The longer a project exists in the 
developmental stages prior to implementation, the longer the resistance movement has 
time to build against it. A strengthened resistance force can eradicate a software project 
faster than anything else [37]. Easily and most importantly, ERPs have been proven to 
work. Any new software development effort can not make this claim. While the chances 
of having a completely successful ERP are not great, the risk of a total failure is much 
higher with a custom software project [38]. 

4. Customization Risk 

Since an ERP is not custom software, an ERP project team has to be wary of 
those that wish to turn it into custom software thereby destroying the value of the 
template. After the cost dispute has been countered with a demonstrated necessity, the 
next source of resistance will be system users that disagree with the way the ERP 
template matches the traditional business processes of the organization. The 
disagreement will occur when the template does not include a process or capability that a 
power user or business baron believes should be in the ERP. If the power organizational 
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player wins the day and the ERP is changed, then the number one pitfall (customization) 
is realized and the organization is in trouble. This is the principal source of ERP pain 
because it makes the system unstable and hard to maintain. It negates the benefit of 
having a proven template and it is the most commonly cited reason for ERP problems 
[17]. 

Every organization is different and a measure of customization is needed by all. 
The important thing is the customization must be kept to a minimum. Capabilities in the 
legacy software may not be in the ERP. There is going to be lost capability in every ERP 
project. On the other hand, to obtain the enterprise wide integration that the ERP is 
attempting to achieve, a measure of sacrifice is going to be required in the hope that the 
benefit more than justifies the sacrifice. Thus, a close examination should be made to 
determine if the capability is a necessity or not. If it is not a necessity it can be discarded 
in the interest of the organization as a whole. Conversely, if the “strong man” of the ERP 
project team concludes that it is a necessity, an interface to the capability is a better 
choice than modifying the core ERP software. To cover the gaps between the necessary 
processes and capabilities and the embedded processes in the ERP, the acronym RICE is 
used. RICE stands for reports, interfaces, conversions, enhancements. It is the order that 
solutions should be sought to cover the gaps. The first possibility to be explored is a 
report. If the same information that is in the legacy system can be retrieved using a report 
out of the ERP, then that is the best solution. Secondly, an interface to a system that has 
the required capability is the next best solution. If that does not work than a conversion 
of the data in the old system into a form that the logic in the ERP can handle is the third 
option. Einally, if nothing else can be done, enhancing the core ERP can take place. It is 
imperative that this option should only be selected as a last resort when there is no 
possible alternative to achieving the capability [39]. 

In order to make determinations about the necessity of processes and capabilities, 
the “strong man” has to be someone at the highest levels of an organization. If it is a 
person that does not have the required power to make and enforce all the decisions 
concerning the ERP, then the organizational barons will win and the result will be an 
extraordinarily expensive piece of custom software that is unstable and can potentially 
bring the organization to a standstill [17]. 
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G. LIFE CYCLE 

Helping organizations avoid the pitfalls navigate through an implementation is the 
ERP life cycle. 


ERP LIFE CYCLE CHART 


Product Evaluation 

Project Management & Consulting 

Training 

JDEtips Journal 


( 1 Complementary Software 

Maintenance & HelpDesk 
Permanent Placement 
Sarbanes-Oxley Compliance 



Product Evaluation — 
Prepare RFP, Evaluate ERP 
Solutions. Sign Contract 


Declining Value — 

Value declines as the ERP solution ages, and 
new business requirements and technologies 
emerge. Upgrading is now nearly as costly as 
implementing a new ERP solution. This phase 
leads to the next Product Evaluation phase. 


Implementation 
Phase I — 

Select Consulting Partner. 
Implement Financials 
(possibly do a Big Bang, 
which would encompass 
parts of the next phase). 
Conduct gO'live readiness 
assessments. 


Maintaining Value — 

Few changes, but an emphasis on 
getting more value from the ERP 
investment. Typical activities include 
a fresh look at business processes, 
and continuing to customize the 
solution where cost justified. 


Extending Value >■> 

Upgrade to current ERP release and 
add complementary functions such 
as EDI, Advanced Planning. CRM. 
SRM, and Business Intelligence. 


Implementation Phase II 
and Beyond — 

Re-evaluate Consulting Partner, 
and continue implementing Core 
ERP functionality, such as: 
Logistics/Manufacturing/ 
HR & Payroll. 


Figure 2.6. ERP Fife Cycle (From: [40]) 
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1 . 


Product Evaluation 


After making the decision to look at ERP software, the first phase of the life cycle 
is product evaluation. During the product evaluation stage, the vision for what the 
organization wants the system to do needs to be established. Before any vendors are 
brought in to demonstrate the capabilities of their systems, the organization has to ask 
itself: what are the requirements of the system that we plan to select? What does it 
absolutely have to do in order for us to conduct business? Where are the areas we are 
looking to improve? Once these requirements are outlined, a request for proposal should 
be issued to some prospective vendors asking them how they handle the key 
requirements. It is beneficial to have the vendors submit screen shots with their 
proposals for the handling of requirements since a picture is worth a thousand words [40]. 

The vendors with the top three proposals should be invited for a demonstration 
day. All of the operational leaders of the organization and head IT personnel who will be 
involved in the project ought to be present for the demonstration to discuss functionality 
and technology. The leaders will also want to use the demonstration time to dissect how 
the corporate culture of the vendor matches that of the buying organization. They can do 
this with questions like [40]: 

• Is this vendor someone you want to do business with? 

• Will they be responsive when you’ve got a dead-in-the-water situation? 

• Does the vendor have a culture that wants to do a fantastic job of taking 
care of their customers? 

• Can they give examples of where they have done that before? 

With the last question, it is especially important to listen for an answer where the vendor 
has done a fantastic job for an organization that is functionally similar to the buying 
activity. The demonstration and the questions that follow will provide enough insight to 
pick an appropriate ERP system. 

2. Implementation Phase I and II 

Implementation is generally not done by the vendor. Usually, an integrator is 
selected to assist the transitioning organization with the implementation. Integrators are 
consulting firms that are helpful when there is not a large body of “in-house” expertise on 
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enterprise systems [41]. The leading integrators in the ERP market are the large IT 
consulting firms such as Accenture, Bearing Point, Computer Sciences Corporations 
(CSC), Price Waterhouse Coopers, EDS, and IBM [2]. Selecting the right integrators is 
critical because they are the link between the organization’s needs and the ERP chosen. 
Additionally, the integrator is going to structure the plan for the implementation so their 
reputation in ERP undertakings at a scale that is equivalent to the one being asked for is 
extremely important [41]. 

The integrator will guide an organization along what is known as the proven path. 
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Eigure 2.7. ERP Proven Path (After: [8]) 

Developed by Daryl Eandvater in the mid-1970s, the Proven Path is a set of well-defined 
steps that an organization should take to successfully complete implementation phase I 
and II of the ERP life cycle. It is a methodology that is followed by integrators and has 
been proven to work because it properly aligns with the priorities of an ERP. The 
priorities for making an ERP implementation successful are people, data, and computer. 
People within the organization are the first priority because of the change that is going to 
take place with an ERP. At all levels of the organization people are going to manage the 
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implementation and either back it or stand against it. Getting positive results is going to 
hinge on getting support for the change. Data is going to come out of the legacy systems 
and go into the ERP and therefore it is imperative that this data is accurate and correctly 
structured. If it is not then a “garbage-in, garbage-out” scenario will result. The last 
priority of ERP is the computer which encompasses both hardware and software. ERP is 
a software initiative and it must be installed and configured correctly for it to work as 
planned. Set to a 19-month implementation timetable, the Proven Path adheres to an 
aggressive schedule because the attention spans of both organizations and people are 
limited. Any one project can only hold the top priority in an organization for so long. 
The monumental shift to an ERP requires that it be the top priority. Since it is unlikely 
that is can hold this position for three or four years, the best tactic is to implement it 
quickly. 


a. Project Organization 

After an ERP vendor and an integrator have been selected, the first step on 
the Proven Path is project organization. This is where the project leader and his staff will 
be selected and the implementation plan will be developed. 

b. Performance Goals 

Along with establishing the plan, the project team will also come to an 
agreement about the goals of the project. Specifically, categories of the business that are 
to be improved will be delineated and the levels of performance those categories are to 
reach will be established. 

c. Initial Education and Training 

Given that people are the first priority in an ERP, educating the people in 
the organization about the change is the top priority in the Proven Path. The goal should 
be to educate 100% of the people affected by the ERP. At a minimum, 80% of those 
people have to be educated. They need to understand why the organization is making the 
transition, what the benefits are and what will be expected of them. If people are going to 
be required to change the way they work, the benefit to doing so must be clearly 
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communicated. Additionally, the powerful entities within the organization should be 
educated on the pitfalls of an ERP so they can help the organization avoid them. 

d. Sales & Operations Planning 

Once education is underway, the sales and operations planning (S&OP) 
portion the ERP can begin implementation. This is first behind education because it 
involves relatively few people but it is the main driver behind the functioning of the 
organization. The sales forecast is a prediction of what is going to be demanded by 
customers. Prom this prediction, the operations plan is set in motion to produce what will 
be demanded. In essence, the S&OP encompasses what the organization does and in an 
ERP it is the most important element. Thus, it is the first element in the implementation 
phase. 


e. Demand Management, Planning, and Scheduling Processes 

Underneath S&OP is demand management, planning, and scheduling. 
Whereas S&OP covers what is going to be required at the highest level, demand 
management, planning, and scheduling is the detail information that goes into the top- 
level forecast. It includes the mix of products that should be made and the specific 
customers that are going to receive those products. Additionally, the new approaches to 
forecasting demand and order entry are covered in this step. The processes are defined 
and a pilot is used to demonstrate those processes. Once the pilot is proved successful, it 
will be implemented and a new customer order entry, forecasting, and detailed planning 
and scheduling processes will be running. 

/. Data Integrity 

Checking the integrity of the data going into the ERP will commence at 
project initiation and continue throughout much of the implementation schedule. Due to 
the fact that ERP requires a level of data integrity that is so high, this step can not be 
underestimated. It is arduous detail oriented work but if it is not done properly, the ERP 
will produce the wrong information. 
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g. Finance and Accounting Processes 

Every action taken by an organization has financial implications. In 
commercial entities, the accounting standards that must be adhered to are well understood 
and codified in ERPs so this step takes lower on the scale of importance in the Proven 
Path. However, for a public organization, the financial processes that are to be followed 
are not as transparent. Either way, the financial processes must be continually defined all 
the way through implementation. 

3. Extending Value 

At the completion of the proven path, the organization can make the decision to 
add the additional features that have come on the market to enhance their ERP. This is 
the step where the particular divisions get those “nice to have” items that are not part of 
standard ERP. Items such as Customer Relationship Management (CRM), Supplier 
Relationship Management (SRM), and Business Intelligence software are costly additions 
to the functionality of the core ERP [40]. The extensions selected should align with the 
strategic goals of the organization. Integration of the ERP with a higher level of the 
corporation or public entity also takes place during the extending value phase of the life 
cycle. 

4. Maintaining Value 

Eive to seven years after the beginning of the ERP project, the maintenance phase 
of the life cycle is entered. During the maintenance phase, the aim is to get as much life 
out of the ERP as possible. An additional five to ten years is ideal. Small improvements 
will be made as business needs change but no major modifications take place [40]. 

5. Declining Value 

At some point the business changes have outgrown the existing ERP. 
Technological advances have changed the landscape and now the organization must 
change again to remain competitive. Approximately twenty years after starting the ERP 
project, in the declining value phase it is time to begin preparations to start the ERP life 
cycle again [40]. 
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III. ERP IN THE DOD 


A. BACKGROUND 

The supply chain problems of the first Gulf War, the ERP success stories of the 
private sector and the legislation passed during the early to mid 1990s steered the DOD 
toward ERP as a viable means of correcting the deficiencies of the Department’s Cold 
War era business systems. In 1997, two internal DOD documents were published that 
emphasized that the time had come to transform the Department’s business environment 
and systems. 

1. The 1997 Quadrennial Defense Review 

The first document to outline the path toward transformation was the 1997 
Quadrennial Defense Review (QDR). In the QDR, the senior DOD leadership outlined 
the current state of the Armed Eorces and defined the direction the Department needed to 
go to face current and future global threats to U.S. security. The 1997 QDR focused on 
this purpose but it also contained a description of the plan to implement “focused 
logistics” [42]. 
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First defined in the DOD’s Joint Vision 2010, “focused logistics” is one of the 
four pillars of “full spectrum dominance”. As a military concept, “full spectrum 
dominance” implies a capability to control all elements of the physical battlespace, 
electromagnetic spectrum and information space using a combination of land, air, 
maritime and space based assets. By controlling these elements, the U.S. would be able 
to prevent the opposing force from operating in these realms [43]. The “focused 
logistics” portion of the operating concept envisioned the services and civilian defense 
organizations working jointly to provide the operating forces precisely the supplies they 
need when they need them. 



Figure 3.2. Focused Logistics (From: [43]) 

To achieve “focused logistics,” the DOD planned to leverage the supply chain 
information systems and business processes of the civilian sector. In the 1990s, the 
commercial sector was continually getting “leaner” by carrying smaller inventories and 
using IT to deliver products to customers at the exact time needed. For many of the 
commercial companies capable of the supply chain practices sought by “focused 
logistics”. The IT enabler of the advanced supply chain business practices was an ERP. 

Placing “focused logistics” as one of the four pillars of Joint Vision 2010 
demonstrated that the DOD intended to make a significant investment in improving the 
way it performed supply chain management. After being revealed in Joint Vision 2010, 
the plan to invest heavily in developing state-of-the-art logistic practices and doctrine was 
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confirmed in the 1997 QDR. The QDR stated that “focused logistics will reduce the 
overall size of logistics support while helping to provide more agile, leaner combat forces 
that can be rapidly deployed and sustained around the globe” [42]. This statement clearly 
demonstrated the shift from the mass inventory methodology of the first Gulf War. In the 
late 1990’s, the DOD planned to put money into ERP systems capable of providing more 
responsive logistics support. 

2. The 1997 Defense Reform Initiative 

After the release of the QDR, the second document published in 1997 to outline 
the course toward transformation was the 1997 Defense Reform Initiative (DRI). 
Chartered by the Secretary of Defense William Cohen, the purpose of DRI was to study 
changes that must be made to the DOD business systems to better meet the requirements 
of the operating forces. The concluding report of the study authorized the services and 
DOD support agencies to begin IT projects to acquire systems that will help the 
Department perform “just-in-time” logistics. Logistics where critical supplies and spare 
parts are not stockpiled just-in-case they are needed but rather are delivered when needed. 
The report states, “Just-in-time logistics is revolutionizing the private sector and can do 
the same for the DOD” [44]. To execute “just-in-time” logistics, the service components 
and DOD logistics components needed to abandon the paperbound logistics systems of 
the past and embrace the IT systems of the private sector. 

B. DEPARTMENT OF THE NAVY 

Given the high level guidance of the 1997 QDR and DRI, the Department of the 
Navy (DON) began to look for the best way to achieve the state-of-the-art logistics 
capability called for in Joint Vision 2010. Additionally, the Navy wanted systems that 
could lead to compliance with the Federal Financial Management Improvement Act of 
1996. In order to meet the requirements of the FFMIA, the systems would have to “... 
comply substantially with (1) federal financial management systems requirements, (2) 
applicable federal accounting standards, and (3) the U.S. Government Standard General 
Ledger (SGL) at the transactions level” [1]. Essentially, what the Navy was looking for 
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was systems that would make the supply chain processes more agile and responsive and 
provide accountability of funds to American taxpayers. 

1. Revolution in Business Affairs 

To achieve this objective, the first thing the Navy did was establish an executive 
committee in December 1997 that was held responsible for looking for ways to transform 
DON business affairs and systems. The committee was dedicated to what the Navy 
called a “Revolution in Business Affairs (RBA)” [2]. A revolution where the Navy 
planned to change the way it traditionally did business in favor of more modern 
approaches. 

2. Commercial Business Practices Working Group 

A goal of the committee for the RBA was to investigate the systems that were 
being used in the commercial sector that provided the information backbone of the 
modem business approaches. The RBA committee did this by forming a separate sub¬ 
committee named the Commercial Business Practices (CPB) Working Group. Made up 
of personnel taken from financial management organizations throughout the DON, the 
CPB working group recommended that ERP systems should be used to drive the change 
that was sought [45]. Based upon that recommendation, six ERP pilot programs were 
authorized but due to a lack of funding, only four pilot programs proceeded. The four 
pilot programs that received funding included [2]: 

• SMART- Aviation Supply & Maintenance: maintenance planning and 
supply support processes sponsored by the Naval Air Systems Command 
(NAVAIRSYSCOM) and the Naval Supply Systems Command 
(NAVSUPSYSCOM). 

• SIGMA- Acquisition Program Management: program management 
processes to include linkage between contracting and financial systems 
sponsored by the Naval Air Systems Command (NAVAIRSYSCOM). 

• CABRIEEO- Navy Working Capital Eund (NWCE) Einancial 
Management: management of the Navy Working Capital Eund within 
acquisition commands sponsored by Space and the Naval Warfare 
Systems Support Center San Diego (SSC-SD). 

• NEMAIS- Regional Maintenance: avionics and repair center processes 
across surface, air, and subsurface communities sponsored by the 
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Commander in Chief Atlantic Fleet (CINCLANTFLT) and the Naval Sea 
Systems Command (NAVSEASYSCOM). 

3. Commercial Business Practices Executive Steering Group 

At the beginning of the projects in December 1998, the Navy established a (CBP) 
executive steering group to monitor the activities of the pilot projects. The executive 
steering group monitored the projects but did not manage the projects. Since the projects 
were individually funded by the sponsoring commands, they were individually managed 
by the sponsoring commands. Furthermore, the separate sponsors had different business 
concerns based upon the particular business function of the supporting activity [45]. For 
example, SSC-SD is a Working Capital Funded (WCF) organization and because of this 
role, it was assigned responsibility for judging ERP’s ability to manage government 
financial management. Specifically, SSC-SD was to judge the following areas [2]: 

• Einancial management- All financial activities including budgets, funds 
management, billings, payables, reporting, and employee data. 

• Procurement management- All buying activities for maintenance, repair, 
and overhaul items, from issuing a purchase order, receipt of goods, and 
processing vendor invoices. 

• Asset management- Including both real property and improvements. 
Tracking all assets from acquisition to disposal. 

• Project management- Eully integrated project management systems that tie 
together project management tools with finance, budgeting, procurement, 
and asset management data. 

• Strategic management- Planning and budgeting tool for both annual and 
long range planning. It will build upon annual budgeting and planning 
needs to develop a long-range orientation for SSC-SD. 

4. ERP and Integrator Selection 

The plan followed by the project teams at the separate sponsoring commands 
adhered to the steps of the ERP life cycle. A business case analysis (BCA) was 
conducted at each of the commands to outline the vision of what the organizations were 
attempting to achieve with their ERPs. The BCAs accomplished this task by outlining 
the “As Is” business processes of the commands and then compared those processes to 
the business processes of an ERP. A side by side comparison revealed the differences in 
the way the work would be performed with an ERP and highlighted the areas where 
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processes would be reengineered and improved by the ERP. The reengineered business 
processes of the ERP were labeled the “To Be” business models [2]. 

Once the vision of what the sponsoring activities wanted to achieve was outlined 
in the “To Be” business models, it was time to select an ERP vendor that best fit the 
model. All of the pilot programs selected SAP’s R/3 (Release 3) software for their 
projects. 
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Eigure 3.3. SAP R/3 Architecture (Prom: [2]) 


The R/3 architecture was chosen because the different business areas of the system are 
divided into modules which allow for certain function points to be implemented while 
others can be excluded or left for implementation at a later time. This provides the user 
with the flexibility to implement in stages thereby reducing the risk associated with 
implementing a system in a single release. Additionally, at the time of the decision in the 
late 1990s, the R/3 software was the preeminent software selected by the U.S. 
Government customers. It was the ERP software of the U.S. Mint, the Strategic 
Petroleum Reserve and most importantly, it was the ERP software the U.S. Army planned 
to use for the Eogistics Modernization Program [EMP] that was underway at the same 
time as the Navy pilots [3]. This is important because the overall goal of Joint Vision 
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2010 was joint operations to include joint logistics. Thus, if the systems were to be tied 
together at some point in the future, it would be beneficial if they were all using the same 
platform. 

Once the product evaluation phase has come to an end, the next step in the ERP 
life cycle (implementation phase I) involves the selection of a consulting partner 
(integrator). A big decision because the ultimate goal is to have a long term partnering 
relationship that has to thrive to keep the ERP project progressing. If the relationship 
turns hostile and the integrator can no longer be considered a trusted advisor, then an 
integrator change has to take place. When an integrator switch occurs, dramatic setbacks 
are the result because it takes time for the new integrator to get acquainted with the 
history of the project [46]. Each of the four separate Navy ERP pilots selected different 
vendors as integration partners for their projects. Eor the SMART pilot, the program 
management team opted to work the Electronic Data Systems Corporation (EDS) while 
SIGMA teamed with Bearing Point. SSC-SD selected Price Waterhouse Coopers for the 
CABRIEEO project and IBM was chosen as the integrator for the NEMAIS pilot. 

5. Pilot Results and Road Ahead 

Between late 1998 and early 2002, the four Navy pilots took different routes with 
their integrators exploring the application of ERP to their business areas. During the 
course of the projects, issues surfaced that required the attention of Navy personnel 
higher than the heads of the Systems Commands sponsoring the individual pilots. The 
main issue that needed attention: what should be done to integrate the pilots after they 
had achieved their independent objectives? This led the Assistant Secretary of the Navy 
for Research, Development, and Acquisition (ASN RDA) to establish a single ERP 
program in August 2002. The goal of the program was the convergence and replace of 
the four pilots by fiscal year 2008 [45]. 

When the decision was made to proceed with a single Navy ERP program, a 
central program office was founded to manage the converged ERP. In the beginning of 
this convergence process, the program office undertook extensive software architectural 
planning due to the fact that the project team was tasked with merging established ERP 
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solutions. A task that is much harder than starting an original ERP project because of the 
care that must be taken to maximize use of the existing SAP instances thereby 
minimizing re-work. 

To make a single ERP solution out of the four pilots a reality, the designers of the 
architecture have approached the project from the perspective that it is like going live 
with an ERP in two divisions of a large company and then merging the divisions into a 
single system. This is typical of the work that has to be done following the acquisition 
and mergers of separate companies. However, before convergence of the systems can 
begin, a vision of the capability that the converged solution is supposed to deliver must 
be established as a target for what the project team is trying to achieve. 


Navy Converged Solution 

Ontegrated Value Chain is the Targeted End State) 



Integrated Single End-to-End Navy Solution Adding Value to the Fleet! 


Eigure 3.4. Navy Vision for a Converged Solution (Erom: [47]) 

Eor the Navy, the vision of the converged solution aligns with the Product Eifecycle 
Management (PEM) approach that is used in industry to manage products from 
acquisition to disposal. In this case, the products to be managed are the major end items 
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that are procured to support the Navy’s mission. The person responsible for PLM in the 
commercial sector is the product manager. A position that is mirrored in the DOD by the 
program manager who "... is responsible for managing the complete weapon system life 
cycle, which includes concept development, R&D, acquisition, testing, initial fielding, 
sustainment (including maintenance), in-service support, and disposal” [47]. 

In their effort to achieve the end-state of a single ERP that manages major end 
items from “cradle to grave”, the Navy has to overcome the fact it has two separate SAP 
instances (SIGMA and SMART) managing aviation assets and another SAP instance 
(NEMAIS) managing maritime assets. The plan developed to handle this situation in the 
most cost effective and risk-minimizing manner calls for the merger of the two aviation 
projects (SIGMA and SMART) into a single instance while NEMAIS will be expanded 
to manage all maritime assets. Integration between the systems will occur because SAP 
was designed to control business functions that flow across organizational divisions 
which in this case is the Navy Systems Commands (SYSCOMS). It does this by 
artificially dividing the software to allow for organizational boundaries while business 
processes between the divisions flow uninhibited across the organizational boundaries. A 
graphic of the arrangement that is envisioned is depicted below. 



Software is "Artificially Divitferi" to Align 
with Existing Organixationai Boundaries 


Eigure 3.5. Current Navy Situation (Erom: [47]) 
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The end-state that the Navy is currently working towards is an operational 
architecture with two value chains (aviation and maritime) that manage the life cycle of 
weapons systems from beginning to end. Both value chains will be include concept 
development, budgeting, acquisition, testing and evaluation, maintenance, in-service 
support, and disposal as well as all the supporting business processes associated with 
these activities. Essentially, the two value chains will conduct the same business 
processes outlined in Figure 3.4 with a different look and feel to maximize the use of the 
work that was conducted on the separate pilot projects. The CABRILLO project of SSC- 
SD will remain separate from the envisioned architecture because as a Working Capital 
Fund organization, the financial process of SSC-SD does not match the financial process 
of the other SYSCOMS. Therefore, CABRIFFO will operate as a stand-alone financial 
stovepipe system [47]. 

C. DEPARTMENT OF THE ARMY 

Fike the Navy, the U.S. Army immediately went to work on focused logistics 
following the release of the QDR and DRI. In August 1997, the Deputy Commanding 
General of the Army Material Command (AMC) issued a memorandum to the 
Communications-Electronics Command (CECOM) that asked the command to [3]: 

a. Determine feasible alternatives for logistics modernization strategies, 

b. consider the implications and devise methods to soften the impact on the 
existing workforce, 

c. develop a performance-based statement of requirements, and 

d. to recommend an acquisition approach. 

Specifically, the Commanding General wanted the CECOM to form a project team tasked 
with conducting market research to explore the IT systems being used by the commercial 
sector. The overall vision the General was working toward was an AMC that integrated 
the best practices and technologies of the private sector to transform the Army’s 
wholesale logistics automation systems. 
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1 . 


The CCSS and the SDS 


Written in Common Business Oriented Language (COBOL), the Commodity 
Command Standard System (CCSS) and the Standard Depot System (SDS) are the 
wholesale logistics automation systems the General was referring to. The purpose of 
these systems was to support the Army’s annual procurement of supplies and equipment 
from commercial vendors, the General Services Administration (GSA) and Defense 
Logistics Agency (DLA). A big problem with the systems is that as of August, 1997, the 
technology being used was thirty years old. The systems were being maintained by 
CECOM funded federal IT employees who worked at two central design activity (CDA) 
logistics centers in St. Louis, Missouri, and Chambersburg, Pennsylvania. It was these 
programmers that the General wanted to “.. .soften the impact on...” if it was decided that 
it was in the best interest of the AMC to adopt commercially available IT systems. 

The problem with the CCSS and the SDS had more to do with their inflexibility 
and unresponsiveness than their age. In their analysis, the project team at CECOM 
tasked with planning the approach the Army should take with their business system 
transformation concluded that the weaknesses of the CCSS and SDS systems are [48]: 

• Lack of flexibility: Process changes, regulatory changes, and 
reorganizations within and between user commands require expensive and 
extensive data conversions and programming changes. 

• Slow, unfocused reports: Reporting and summarization capabilities are 
geared to workers. Managers and executives, with their need for easily 
specified, flexible, tailored, and rapid generation of reports and summaries 
are usually frustrated with output capabilities. 

• Difficult to use: The system is not user friendly. The system relies on 
extensive use of codes to provide compact storage (a holdover from the 
time when computer storage was inordinately expensive). Users are 
required to learn codes and have extensive system knowledge. The system 
lacks adequate data edits and validations, as well as support functions. 

• Expensive to maintain: The system’s size and complexities make it 
difficult to manage and change code. Earge portions are based on 
relatively old third-generation programming languages and flat data 
structures that are inflexible to change and inefficient to operate. 

• Unresponsive: The use of batch processing precludes timely updates to 
data architecture, flexible data retrieval capabilities, and informed 
decision-making. 
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• Outmoded database: The use of outmoded database systems and 
architecture result in rampant data inconsistencies, data duplication, and 
the lack of data standardization. 

• Expensive to operate: The system requires extensive manual intervention 
because of outmoded data and system architectures. 

• Lack of cost-sharing: The Army is the only “bill payer,” precluding the 
ability to leverage existing industry investments in modern logistics 
processes and IT. 

After identifying the problems with the legacy systems, the project team had to come-up 
with a solution using the $426 million operating budget that was set aside for operations 
and maintenance of the existing systems for the period between 1997 and 2007. As was 
done with the Navy pilot projects, the Army planned to use the operating funds of the 
sponsoring command to fund the transformation effort. In the Army’s case, the 
sponsoring command was the AMC. 

3. The Army’s Plan to Modernize 

Three alternatives were devised by the CECOM project team to achieve the 
reengineered logistic processes and modernized systems. The first alternative was ruled 
out because it did not meet the cost constraint and the schedule was deemed too lengthy. 
Alternative two was a financially viable option but there was no “soft-landing” for the 
478 federal programmers at the two CDAs. Consequently, it was feared that a hostile 
relationship would develop between the contractor personnel and the CD A employees. A 
situation that would likely result in government employees sabotaging the program. The 
last alternative was the only option that met the mandate of a “soft-landing” for the CDA 
programmers and fell within the budgetary guidelines. 
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INVESTMENT/IMPLEMENTATION 



* I^■^■ESTME^■T=C OST TO GO\XRNMENT THROUGH DEPLOYMENT 


Figure 3.6. Investment/Implementation Comparison (From: [3]) 

In the seven year period between fiseal years 1999 and 2005, the modernization project 
would cost $253.5 million. The ten year cost of the project (1999 to 2009) was projected 
to be $420.9 mi llion. A savings of $4.3 million would be realized and the federal 
programmers would receive their “soft-landing” because “Under alternative three, the 
soft-landing was an arrangement in which the winning contractor would agree to employ 
the government employees affected by the transition for a pre-specified period of time, 
offering competitive pay and benefits” [3]. Alternative 3 had the lowest price tag 
because the winning contractor would have to be willing to operate at a loss during the 
system development phase (through FY-2005) while the new system is being built and 
the old systems are still being maintained. The winning contractor would recoup their 
losses over the life of the contract because they would be awarded the contract for the full 
ten years and receive all of the $420.9 million. Losses would be offset in the later years 
by gains that would be realized due to the efficiencies of the new system. 

3. Privatization 

Translating the plan outlined in alternative three into reality required privatization 
because the plan called for the movement of government equipment and personnel into 
the private sector [49]. In the Spring of 1998, the privatization plan encountered 
resistance from the Office of the Secretary of Defense (OSD) who told the project team 
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that what they were planning was an outsourcing initiative and thus, the team would have 
to follow the guidelines established in the Office of Management and Budget (0MB) 
Circular A-76. The A-76 mandates that federal employees be allowed to compete against 
private companies for a contract such as the one proposed. A downside of the 
competition is that if the federal employees lose the competition, they also lose their jobs 
[49]. The project team did not want such a competition to occur because they knew that 
the CDA employees did not have the business process reengineering and IT skills 
necessary to successfully compete for the contract. If they lost the contract and lost their 
jobs, the team would have failed to provide them the “soft-landing” that the AMC 
Commanding General desired. Therefore, the project team began to look for a way 
around the requirements of the A-76 and found what they were looking for in the Circular 
itself. The Circular contains a clause which allows for agencies to submit an application 
for a waiver if there are extenuating circumstances. Using the CECOM attorneys, the 
project team drafted their waiver request containing the justification for their acquisition 
approach. The waiver was the first ever submitted and was approved by the DOD chain 
of command in April 1999 [3]. 

4. The Union Battle 

Upon notification that the waiver was approved, the CDA employees began to 
fight in order to stop the process. Many of the employees did not want to transition out 
of the federal workforce and the St. Louis workers were unionized under the National 
Federation of Federal Employees (NFFE). The NFFE filed an appeal with the Army in 
May 1999 and got the attention of the Congressional representative in St. Louis, Dick 
Gephardt. Though not under a union, the Chambersburg CDA employees also got the 
attention of their Congressional representative and the battle to keep the project alive got 
underway in Washington. Using the logic that outsourcing was the only way the Army 
was going to make a significant transformation, the project team beat out the resistance. 
In addition to the reason in the argument, the fact that the project team had developed a 
plan to take care of the Government employees helped to win over lawmakers and the 
DOD leadership. On September 30, 1999, the Secretary of the Army rejected the NFFE 
appeal and the project moved forward [50]. Due to the fact that the Army secretary was 
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the ultimate authority in the decision, his rejection ended the fight. Still, when the time 
came for the CDA employees to accept job offers from the winning contractor, only 205 
of the nearly 500 civil service employees went to work on the project. The others opted 
for early retirements or transferred to a different federal sector [51]. 

5. The WLMP Gets Underway 

With the demise of the CDA employee resistance in the Fall of 1999, the only 
thing left to do at the end of that year was award a contract. On December 30, 1999, the 
AMC selected the Computer Sciences Corporation (CSC) as the integrator for the 
Wholesale Logistics Modernization Program (WLMP) more commonly referred to as the 
Logistics Modernization Program (LMP) [3]. The task assigned to CSC: “...provide 
business process re-engineering services for the Army’s current wholesale logistics 
processes and supporting IT” [52]. To accomplish this task, the system chosen was the 
same system selected for the Navy’s pilot’s, SAP’s R/3. CSC immediately went to work 
on the LMP and by November 2002 end-user training and testing was underway with test 
designed to see if the LMP met the requirements established for it by the AMC [53]. 
Having passed the initial testing, LMP deployment occurred in February 2003. 

6. SALE 

While the LMP project team was handling wholesale logistics support, the AMC 
got started working on the retail side of the support equation. Retail customers are the 
field-operating commands that support Army units in combat. They are the units that 
requisition the supplies from the wholesale level that is holding the inventories of stocks. 
Both the retail and wholesale projects were started in the late 1990s. However, the 
programs were divided because the plan for what was to be done with the federal 
employees responsible for development and maintenance of the legacy systems was 
different. As was discussed previously, the wholesale programmers at the two CDA were 
to be retired, transferred or handed over to the winning contractor. Unlike the legacy 
wholesale environment which had two main programs (the CCSS and SDS), the legacy 
retail environment contained sixteen separate programs with thousands of federal 
employee programmers. This problem led to the decision that the federal employees 


51 



should continue to operate the legacy systems while working with a contractor to develop 
a new system [51]. Work on the new system began in 1999 but it has had a much 
lengthier development timeline than the LMP because of the transitional approach taken. 
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Figure 3.7. GCSS-Army System Migration Diagram (From: Ref. [54]) 

Titled Global Combat Support System-Army (GCSS-Army), the retail project is 
still in the early stages of development having only met Milestone B of the Integrated 
Defense Acquisition, Technology, & Logistics Lifecycle Management Framework in 
March of 2007. The vision for GCSS-Army is that it will provide the Army supply clerk 
embedded with the fighting forces a single application for tactical logistics at home and 
overseas. It will achieve this end-state by slowly transferring the capabilities of the 
multiple systems currently in use into a single system running on an SAP R/3 framework. 
The framework currently in development has been specially designed and standardized 
with other Joint and NATO partners to meet the requirements of the modern battlefield 
[55]. 

When the LMP and GCSS-Army are brought together, they will form the Single 
Army Logistics Enterprise. 
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What is Single Army Logistics Enterprise (SALE) 
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Figure 3.8. What is Single Army Logistics Enterprise (SALE) (Erom: [55]) 

There is an additional entity in the SALE architecture that will act as the integrating hub 
between the LMP and GCSS-Army. Product Lifecycle Management Plus (PLM+) is a 
copy of what was seen in the Navy’s Converged ERP Solution and ties the whole system 
together by structuring the data so that every aspect of the life cycle of a weapon system 
can be viewed in one system. Using SAP’s Master Data Management (MDM) 
technology, the SALE mandate calls for just one common SAP enterprise controlling all 
the logistics data and managing the interfaces to external sources that have technical data 
or information of value to those involved in the life cycle of Army equipment and 
supplies. Integrating the LMP, PLM+ and GCSS-Army will achieve the overall vision of 
SALE which is “A fully integrated knowledge environment that builds, sustains, and 
generates Warfighting capability through an integrated logistics enterprise based upon 
collaborative planning, knowledge management, and best business practices” [55]. The 
teaming arrangement between the Army and CSC to achieve a SALE running on an SAP 
ERP is the future of Army logistics. It is anticipated that this will be realized with full 
operational capability in 2014. 

D. DEFENSE LOGISTICS AGENCY 

Established in 1961, the Defense Logistics Agency (DLA) falls under the control 


of the Under Secretary of Defense for Acquisition, Technology, and Logistics 
(USD/AT&L) [56]. The role of DLA in the DOD is as a centralized intermediary supply 
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support agency that procures consumable items from the commercial market and then 
distributes those items to the separate service components. “DLA’s critically important 
role in national security is clearly reflected in the fact that the military services rely on the 
agency for 100 percent of their subsistence items, medical material, construction and 
barrier material, footwear and protective garments...all the essentials of personal 
readiness” [57]. For the major end-items that the military services fly and drive such as 
planes, tanks, planes, and trucks, DLA provides close to 95 percent of the repair parts that 
are required to keep these items operational. The agency is able to accomplish its 
mission through a requisitioning system where the customers (military services) 
determine their consumable requirements and then submit orders to DLA. Depending 
upon the material requested, the order will be forwarded to one of four supply centers for 
action. In the U.S., the four supply centers operated by DLA are [56]: 

1. Defense Supply Center Columbus, Ohio, which is responsible for land, 
maritime, and missile support; 

2. Defense Energy Support Center, Fort Belvoir, Virginia, the lead center for 
comprehensive energy solutions, such as contract support and the 
management of petroleum-based fuels; 

3. Defense Supply Center, Richmond, Virginia, which is responsible for air, 
aviation, and space support; and 

4. Defense Supply Center, Philadelphia, Pennsylvania, the lead center for troop 
support items, such as food, clothing, and medical supplies. 

Upon receiving a requisition at a supply center, the center will meet the need in one of 

two ways. It will either be directly shipped or released from the commercial vendor who 

provides the material or fuel, or it will be distributed to the customer out of one of the 

DLA’s owned distribution depot. 
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Vendors 


Figure 3.9. DLA’s Supply Chain Management Process (From: [56]) 

In addition to supporting military end-items while they are in operation, the DLA 
is also instrumental when the items reach the end of their lifecycle. At the end of military 
equipments “functional life” or when it is no longer of value to the owning organization, 
it is turned over to a DLA Defense Reutilization and Marketing Office (DRMO) for 
reuse, reutilization, or disposal. 

1. Business System Modernization 

As the “...bridge between the warfighter and the American industrial base...” 
[57], it was clear to DLA leadership when the QDR and DRI were published that the 
agency was going to play a key part in “focused logistics”. Prior to the release of these 
documents, DLA had concentrated on being a manager of the physical inventories that it 
carried in controlled depots. Since the focus was internal, the systems used were also 
developed internally. The future of DOD logistics that was mapped out in the QDR and 
DRI shifted the focus of DLA from an inventory management mindset to a supply chain 
management mindset [58]. Due to the fact that DLA holds such a pivotal position in the 
DOD supply chain, “focused logistics” would never become a reality if the Agency 
continued to rely on the thirty year old Standard Automated Material Management 
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System (SAMMS) and Integrated Subsistence Management System (ISMS). When 
compared to industry, DLA is a massive enterprise with a scope of business that includes 
[57]: 

• 54,000 Requisitions/Day 

• 8,200 Contracts/Day 

• Number 54 on the Fortune 500 

• Number 2 in Top 50 Distribution Warehouses 

• 26 Distribution Depots 

• 5.2 Million Items 

• 24.7 Million Annual Receipts and Issues 

With supply chain statistics similar to the behemoths of industry, the logical decision was 
for DLA to look to industry for answers on how to reduce inventory, deliver faster and 
lower IT costs. 

In July 1998 DLA’s Business System Modernization (BSM) program was born 
with the establishment of the Modernization Executive Board (MEB). The top-level 
objectives of the board were [59]: 

• Replace Eegacy Systems with commercial-off-the-shelf (COTS) software. 

• Reengineer by fielding Best Practices. 

• Improve customer service by collaborating with suppliers and customers. 

• Provide Best Value Solutions. 

• Provide the training, experience, and opportunity to succeed. 

Eollowing the ERP life cycle toward achieving these objectives, the first thing the 
MEB did was conduct a course of action analysis to determine if an ERP was an 
appropriate solution to transition DEA from inventory manager to supply chain manager. 
Having completed the exploratory phase in January of 1999, DEA’s ERP project team 
began process mapping in April of 1999 to compare the DEA’s traditional business 
processes versus the ERP business processes. In the summer of 1999, ERP vendors 
demonstrated how they would perform DEA’s business functions. The system 
requirement were further refined in the Eall of 1999 and on December 2L\ 1999, the 
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DOD approved DLA to move forward with the project and award a contract to a systems 
integration partner [56]. Accenture was selected as the integrator for the BSM in August 
of 2000 and awarded a $700 million contract to help DLA institute an enterprise-wide 
system [60]. 

2. The DLA’s Plan to Modernize 

To distinguish between the different categories of supplies, the DOD had 
separated the military supply system into a class of supply. The classes of supply are 
[57]: 

• Class I (Subsistence) 

• Class II (Clothing and Textiles) 

• Class III (Bulk Petroleum) 

• Class IV (Construction and Barrier Materials) 

• Class V (Ammunition) 

• Class VI (Personal Demand Items) 

• Class VII (Major End Items) 

• Class VIII (Medical Material) 

• Class IX (Repair Parts) 

• Class X (Non-military requirements) 

In the DLA’s implementation phase one of the BSM life cycle, the plan called for 
capturing the core processes related to the classes listed with the exception of Class III 
(bulk petroleum). Class V (ammunition). Class VI (personal demand items). Class VII 
(major end items), and Class X (non-military requirements). Class V, VI, VII, and X 
have never been the responsibility of DLA. Class III supplies were to be handled by the 
Luels Automated System (LAS). Also a COTS software package, the LAS system was 
started as a parallel program to the BSM but it was developed solely to help DLA manage 
$5 billion worth of petroleum contracts each year [58]. Not including petroleum, the 
BSM blueprint was designed so that the ERP would fulfill DLA’s core business 
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processes relating to planning, procurement, order fulfillment, and financial management 
for the other classes of supplies managed. 
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Figure 3.10. BSM Business Blueprint (From: [59]) 

Like the Army the Navy, DLA selected SAP R/3 software for the BSM ERP. 
Additionally, Manugistics and PD2 software was also chosen to supplement the SAP 
software. A Manugistics package was bought to manage demand history/forecast, 
develop the time phased inventory plan, create the supply plan, evaluate demand plan 
performance and optimize the distribution network. PD2 was procured to manage vendor 
master records, purchase requisitions and solicitations. It was also to be used for 
converting the supply plan and evaluating quotes. By purchasing these separate software 
platforms, DLA felt that it had achieved two of its top objectives: replace legacy systems 
with commercial-off-the-shelf (COTS) software and provide best value solutions. 

Within each core business process, reengineering targets were established for the 
ERP so that the project would achieve two other top level objectives: reengineer by 
fielding best practices and improve customer service by collaborating with suppliers and 
customers. Eor the planning process the goals for reengineering included: demand for 
items should be set by the customer, a time-phased inventory plan, and a budget based on 
that plan. In procurement, the objectives were set at: tracking supplier performance and 
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supplier management, web-based procurement, and paying vendors upon receipt of 
material. Financial management was concerned with: FFMIA compliance, financials 
integrated with business transactions, and a change in inventory valuation methodology. 
Finally, to improve order fulfillment, DLA wanted the ERP to provide: time definite 
delivery, variable pricing, on-line account visibility and most importantly, to deliver 
material to the customer as promised. Requirements for the system were written so that 
scenarios could be run to test if these reengineering objectives had or had not been met by 
the software. Originally, the BSM project team scheduled full operational capability for 
the BSM in 2005. To successfully move forward through the aggressive schedule that 
was established, the system had to meet more than eighty percent of the functional 
requirements in the operational requirements document (ORD). Between 2001 and 2005, 
the program did fall slightly behind schedule. The actual schedule the BSM followed is 
outlined below. 



Figure 3.11. BSM Timeline to Date (From: [59]) 
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3. Phase II and Future Projects 

At the outset of the BSM, DLA intended to go beyond phase I of the ERP life 
cycle. As early as 2001, there was talk of transitioning into implementation phase II and 
beyond of the life cycle at the conclusion full operational capability (FOC) with the BSM 
[59]. FOC for the BSM was achieved in late 2006 and DFA is currently working hard to 
progress into implementation phase II and beyond as well as making plans for the 
extending value phase of the ERP life cycle. Eight key initiatives have been started to 
help DEA work toward the vision of being a critical enabler of “focused logistics.” 
These eight initiatives are [57]: 

a. Customer Relationship Management (CRM) 

An extension of the ERP, a CRM system will help DEA structure and 
standardize customer relations so that issues are resolved in a timely and effective 
manner. A CRM is capable of doing this because it establishes a single enterprise-wide 
process for classifying customer issues and then managing those issues through 
resolution. The goal of a CRM is not just handling complaints and requests for status, 
they also provide sales and marketing services as well. By implementing a CRM system 
DEA is anticipating: 

• Increased knowledge of customer’s needs. 

• Easier customer access to DEA. 

• More timely and accurate reporting on key customer metrics. 

• Tailored solutions based on customer unique needs. 

• Enhanced ability to improve readiness and customer satisfaction at a 
reduced cost. 

• Increased ability to support DOD strategies of Focused Eogistics. 

• Increased effectiveness in managing customer expectations and agency 
investments. 

• Enhanced collaboration through collection and sharing information across 
the enterprise. 

• Reduced customer complaints. 
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b. Supply Relationship (SRM) 

Also an extension to the ERP, an SRM system enhances the ERP by 
delivering improved communication with suppliers so DEA can streamline the supply- 
chain and reduce inventory by having products shipped directly from vendor to customer. 
To make strong customer/supplier relationships requires a great deal of trust between 
organizations and an SRM system helps to build that trust by providing DEA “...more 
accurate insight into suppliers’ capabilities and suppliers with more insight into DEA’s 
needs” [57]. An essential enabler of this relationship is the Electronic Data Interchange 
(EDI) which links vendors and DEA so that requisitions can be passed straight to vendors 
for delivery without the need for the material to be received and redistributed by DEA. 
Also, a SRM system helps to track vendor performance so the Supply Chain Alliances 
(SCA) can be built with the vendors that habitually deliver quality products and services. 
All of the benefits to an SRM fall under the SRM umbrella. 
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Eigure 3.12. SRM Umbrella (Erom: [57]) 

Over the course of the next several years, it is expected that DEA’s SRM will: 

• Reduce delivery times and total ownership costs 

• Provide inventory savings 

• Increase two-way communication with suppliers 

• Eeverage buying power across the enterprise 
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c. Distribution Planning and Management System (DPMS) 

The DPMS is the delivery vehicle for dramatically improving the shipping 
processes used to get material into the hands of the warfighters. Using a combination 
COTS and government-off-the-shelf (GOTS) software, the DPMS will manage the 
movement of material in the Continental United States (CONUS) and outside the 
Continental United States (OCONUS). Customers and vendors alike will be linked into 
the DPMS and provided real time visibility of the location of their inbound and outbound 
material. Such visibility will increase the confidence of all parties that material will 
arrive at the time promised. It is also predicted that the DPMS will allow for the shifting 
of material in route so that the prioritized end-user is receiving the material they need to 
fight. Customer Wait Time (CWT) will be reduced and Time Definite Delivery (TDD) 
will be a reality. 
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Figure 3.13. DPMS Program Architecture (From: [57]) 
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d. Integrated Data Environment (IDE) 

A centralized repository for all the of the DOD’s supply chain 
management data is needed so that costly system-to-system data interfaces can be 
reduced. That is the purpose of the IDE. It will function as the authoritative source of 
logistics information and all of the other logistics automated information systems will 
access it to retrieve the information they need to support the logistics enterprise. 
Information such as the correct location of a unit will be maintained in the IDE so that 
material is delivered to the right place. IDE will eliminate the need for such information 
to reside in multiple systems. 

e. National Inventory Management Strategy (NIMS) 

In an effort to break down the barrier between the wholesale and retail 
levels of supply in the DOD, DEA has created the vision for NIMS. Designed to track 
consumable supplies from the wholesale level to the point where the item is handed off to 
the ultimate customer, NIMS will establish a single inventory of all consumable stock so 
that DEA can tailor stocks by site thereby improving customer support. No longer will 
the wholesale level lack visibility of what is being kept at the retail level. Historically, 
this lack of visibility has resulted in redundant inventories being kept at both levels 
because it is unknown what is where. A cornerstone of the NIMS concept is that DEA 
would own the inventory no matter where it is stored until it is sold off when 
requisitioned by an end-user. 
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DLA, service, and site will 
negotiate Inventory 
management solutions, 
creating a tailored logistics 
solution by site. 


□LA owns the Inventory 
Investment to end-user point 
of sale. 


Retail pass-through charges 
for DLA materiel are 
eliminated. 


Figure 3.14. The NIMS Vision (From: [57]) 

/. Global Stock Positioning (GSP) 

GSP is an initiative to reduce the number of distribution centers necessary 
to support DLA’s mission. It is a consolidation effort that is being undertaken because of 
the reduced levels of inventory that will be carried as result of the ERP. The goal of the 
GSP is to maintain the inventory that is carried at the right locations so the supply system 
is responsive to customer demands. With the GSP, there will be an increase in the 
number of combined distribution centers supporting co-located customers. “By 
implementing the GSP, DLA is ensuring that the right inventory is at the right locations 
to meet warfighter requirements. The result: reduced costs, reduced customer wait times, 
improved warfighter readiness and a reduced logistics footprint” [57]. 

g. Product Data Management Initiative (PDMI) 

Currently, most of the technical manuals relating to the products DLA 
buys are kept manually. The PDMI is aimed at automating the maintenance manuals and 
operating procedures for the products DLA manages. Once automated, the 
discontinuities of the manual documents will be eliminated and customers will have 
access to the most up to date technical data about an item being ordered. Programs such 
as the PDMI have proven successful in the commercial sector and through the 
reengineered business processes and COTS software, DLA hopes to have: 
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• a single virtual workspace for all technical users; 

• a standardized, enterprise-wide business process supporting all product 
and product data specialists and related staff; 

• a fully automated, modernized, and re-engineered set of technical business 
processes that will significantly contribute to and improve DLA’s overall 
cross-function and cross-process responsiveness to its customers; 

• automated management of technical and product data used in support of 
DLA managed items; 

• technical business processes, including links to technical specifications, 
drawings, manuals and transaction data; 

• complete visibility into all product and technical data associated with DLA 
items, including the ability to provide this visibility to DLA’s customers in 
coordination with the CRM initiative; 

• a reliable ability to exchange documents and forms with service design 
activities; 

• a reliable, robust, and seamless interface with BSM’s SAP application, 
which will enable true cross-process functional flows; 

• a reliable, robust and wholly automated document management function to 
support both PDMI and the BSM suite of applications, including bid set 
and bill of material (BOM) support; 

• a replacement for Joint Engineering Data Management Information and 
Control System (JEDMICS) based on contemporary technologies; and 

• a COTS and standards based application that will provide cost-effective 
sustainment and enhancement capabilities. 

h. Reutilization Modernization Program (RMP) 

The last initiative that will work to modernize the complete life cycle of 
the material procured by DEA is the RMP. Created to replace the Defense Reutilization 
and Marketing Services (DRMS) current IT systems, the RMP is COTS software that will 
easily fit together with the BSM ERP. When the RMP is in place, DEA will have digital 
access to all the data about an item from procurement to disposal. 

E. THE UNITED STATES MARINE CORPS 

While the Navy, Army and DEA were getting their separate ERP programs 
started in the late 1990s, the Marine Corps delayed starting any projects until studies 
were done to analyze the problems with the Marine Corps’ current logistics environment. 
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Named the Logistics Information Resource (Log IR) Strategic Plans, the studies 
concluded in 1998 that much like the other service branches, the Marine Corps was also 
running old, non-integrated systems that were not keeping pace with the modem logistics 
practices of the public sector. Specifically, the non-integrated, stovepiped processes and 
systems resulted in a complex logistics chain designed to support peacetime operations. 
In war, the processes used to support combat operations change and therefore, the Marine 
Corps support personnel are required to learn new processes and systems while moving 
with the combat forces engaged in battle. 
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Figure 3.15. Current Logistics Chain in Garrison and Deployed (From: [61]) 

Additional problems with the Marine Corps’ logistics chain include [61]: 

• Multiple complex processes exist that must be managed at the supported 
unit level. Numerous specialized systems and skills are required, placing 
the burden on the warfighters to fulfill their own logistics needs and 
detracting form their fundamental core competency-to execute combat or 
combat support operations. 

• Inadequate information visibility exists along the Marine Corps logistics 
chain to support informed logistics planning and execution decisions. 
Today supported units do not have visibility regarding status of their 
requests for products, and/or services, service capacity (e.g., people, 
equipment) available to fulfill their requests, and inventory available 


66 































within and outside the Marine Corps (e.g., Defense Logisitics Agency 
(DLA) and vendor inventory) to fulfill their requests. 

• This lack of near real-time information sharing is leading to demand 
uncertainty and mountains of excess inventory (i.e., safety stock). 

• Inventory is managed and positioned by class of supply and according to 
doctrine and policy, with very little understanding of the importance of the 
individual end item to mission accomplishment and the ability of the 
global supply environment to support the demand. This results in large 
amounts of redundant and layered inventory (the “Iron Mountain”) being 
maintained along the logistics chain. 

• Numerous and conflicting metrics exist, with most not aligned to Marine 
Corps strategic goals. 

1. The Blueprint 

Once the problems with the logistics environment were identified, the Marine 
Corps decided that a logistics operational architecture (Log OA) needed to be designed to 
remedy the situation. In December 2000, work on the Log OA got started and shortly 
after initiation, it was determined that best architecture would be one that can be used in 
both garrison and deployed. 
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Figure 3.16. Future Logistics Chain in Garrison and Deployed (From: [61]) 

Thus, the resulting architecture called for a single process that could deliver material 
from “factory to foxhole” [61]. 
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To complete the envisioned integrated architecture, the Marine Corps Logistics 
Modernization (Log Mod) program was started in late 2003 with the launching of six 
initiatives encompassing the different aspects of the program [61]. 

a. Log OA 

The first initiative was an expansion of the original Log OA and was 
created to map out the details of a single end-to-end process for Logistics Chain 
Management (LCM) based upon the recommendations of the commercial sector. An 
expanded Log OA is the foundation for the Log Mod as a whole because it encompasses 
all of the actions and interfaces that must take place to fill a request. The Log OA also 
blueprints the communication assets and personnel structure that should be in place to 
implement commercial logistics best practices. Finally, the Log OA includes a plan for 
capacity management analysis for products, services and transportation assets as well as a 
plan for In-Transit Visibility (ITV) and Total Asset Visibility (TAV). 

h. Log C2 

To route request and provide the visibility to all the parties involved in the 
Log OA, an extensive telecommunications network must be planned for. The Log C2 is 
the initiative that was started to cover this portion of the Log Mod program. 

c. CSS R/R 

Historically, three active duty Force Service Support Groups (FSSGs) 
support all Marine Corps ground logistics for the three Marine Expeditionary Forces 
(MEFs). Each of the ESSGs is uniquely organized to support the different command 
structures. This arrangement is not consistent with the requirements of the Eog OA. 
Therefore, the Combat Service Support Rename/Reorganize (CSS R/R) initiative was 
started to rename and reorganize the ESSGs to align with the Eog OA. It is also expected 
that the CSS initiative will provide more consistency to the ESSGs in terms of size and 
structure because under the CSS R/R framework, the organizational structure is identical 
for I, II and III MEE. 
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d. MAGTF Distribution 

The Marine Air-Ground Task Force (MAGTF) Distribution initiative was 
started to oversee all the aspects of physical material flow. Due to the fact that a critical 
requirement of the Log OA is ITV, every delivery platform in the end-to-end supply 
chain must be integrated to provide visibility of assets as they travel the path to and from 
the customer. MAGTF Distribution is responsible for making that integration happen so 
that all transportation assets within the MAGTF and external to the MAGTF are linked 
into the architecture to provide updates on material location. 

e. ROM 

Poor maintenance effectiveness and a lack of available operational 
equipment has been the result of the Marine Corps’ five Echelons of Maintenance 
(EOMs) for ground equipment [61]. Consequently, the Realignment of Maintenance 
(ROM) initiative institutes the three levels of maintenance used in the air side of the 
MAGTE. Under the ROM, there will be an Operator/Crew level, a Eield level and a 
Sustainment level. 
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Eigure 3.17. The 3 Eevels of Maintenance (Erom: [61]) 

Every piece of ground equipment currently in use will be realigned to the three levels of 
maintenance system. Moreover, all new acquisitions of ground equipment must also 
adhere to the three level system. 
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f ROS 

Covering the inventory management aspect of the Log Mod is the 
Realignment of Supply (ROS) initiative. In the 1960s through the 1980s, order 
processing cycles took a long time. Consequently, the Marine Corps invested heavily 
into stocking material at the different levels of the supply chain to ensure availability of 
material. Managing these large inventories is cumbersome and requires a substantial 
outlay of funds. This problem led to the ROS so that the Marine Corps can focus on 
order management and move away from inventory and warehouse management. The 
targeted objectives for ROS are [62]: 

• Remove the responsibility for request management from the supported 
unit to allow it to concentrate on its primary mission, implement request 
management [end-user function] and order management functions 
[supporting supply agency function]. 

• Centralize the responsibilities for order fulfillment and capacity 
management of both inventory and procurement in one supporting unit for 
each MAGTF. 

• Manage product inventory in the logistics chain according to its criticality 
to the mission and its relative availability. Do not stock easy to obtain 
non-critical items and make heavier use of outside sources (e.g. DLA and 
vendor managed inventory) for these items. 

• Track orders and provide in-transit visibility and total asset visibility 
across the logistics chain. Introduce performance management for 
inventory and product order management. 

• Integrate ROS with related Navy, DLA and Joint programs such as Naval 
Logistics Integration, DLA NIMS, JEMMS, etc. 

• Integrate supply with distribution according to best logistics chain 
management practices. 

• Introduce enterprise-level inventory and inventory capacity planning to 
optimize the flow and minimize costs across the logistics chain. 

An essential part of the ROS is the integration of the new supply chain processes 
with organizations external to the Marine Corps. Due to the fact that a large part of the 
Marine Corps ground equipment is common to the Army, the Log Mod is going to have 
to communicate with the Army’s LMP in order to requisition material from the wholesale 
level for the Army/Marine Corps common operational assets. Primarily, the Log Mod is 
concentrating on the retail level of supply because with the ROS, it is hoping to abandon 
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as much inventory management and warehousing functions as possible. By relying on 
the Army’s LMP and DLA’s NIMS initiatives, there is great potential for a massive 
reduction of Marine Corps owned inventory. There are nearly 500,000 items unique to 
the Marine Corps that will have to be planned for, but the Corps will be looking for DLA 
and the individual vendors to manage the inventory for most of these items [61]. As was 
stated in the list of objectives, the Marine does not want to “...stock easy to obtain non- 
critical items...” All that will be carried in inventory by the Marine Corps is equipment 
unique to the Corps that is hard to get. Aviation material for the Marine Corps’ aviation 
assets is not planned for in the ROS because Marine Corps aviation is funded directly by 
the Navy. Hence, any changes that take place with the Navy ERP that affect Naval 
aviation will also apply to Marine Corps aviation. 

2. Processes, Technology, and People 

To tackle the objectives set out in the Log Mod, a plan has been developed that 
includes a three prong assault including processes, technology, and people. It has been 
determined that these are the three things that must fundamentally change in the Marine 
Corps for the Log Mod to succeed. 




Ligure 3.18. Change Elements of Log Mod (Lrom: [61]) 

The Marine Corps is looking for logistics processes that “...can support any unit, 

in any situation, anywhere” [61]. These processes are depicted in the Log OA and 

provide the architectural framework for streamlining the logistics chain to support future 

Marine Corps operations. Changing processes must be supported with an investment in 
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IT. In-line with the Army’s naming convention, the Marine Corps has adopted the name 
Global Combat Support System (GCSS) as the name for the portfolio of COTS systems 
that will be implemented to replace the current logistics systems. Given that the Marine 
Corps GCSS and the Army’s GCSS are both focused on the retail piece, the name is 
fitting. GCSS-MC is the official name of the Marine Corps system so that it is 
distinguishable from the Army’s. Finally, since the new processes and systems must be 
run by people, the personnel structure and training in the Marine Corps must change so 
that it fits with the new processes and technology. Moreover, the Marine Corps Log Mod 
team recognizes change management must be incorporated into the program so that it can 
overcome the resistance that will occur as a result of the implementation of new business 
processes. The change management plan is covered in the people portion of the overall 
strategy. 

3. The Timeline 

An incremental timeline has been instituted with the Log Mod being completed in 
blocks so that it aligns with the Program Objective Memorandum (POM) financial 
practice that is used in the U.S. Government. 
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Figure 3.19. GCSS-MC Capabilities (From: [61]) 

Block one of GCSS-MC provides the initial capability of the system and includes 


such things as the functionality to support deployed operations, inventory management, 
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maintenance management, and service management. Within block one, the following 
legacy systems are to be retired: Supported Activities Supply System (SASSY), Marine 
Corps Integrated Maintenance Management System (MIMMS), PC MIMMS, and Asset 
Tracking, Logistics, and Supply System (ATLASS I) [62]. The operational requirements 
document for GCSS-MC was completed in late 2003 and it was established as a program 
of record to receive funding in the Fiscal Year 2004 POM [63]. All remaining 
requirements to get block one completely funded were completed in June 2006 and the 
program is fully funded in the 2008 POM. Currently, the Marine Corps is working the 
requirements for block two with a scheduled completion date of June 2008 so that it can 
be funded in POM 10. Between July 2008 and June 2010 block three will be outlined for 
funding in POM 12. Full operational capability (FOC) of the Log Mod system as a 
whole is anticipated by 2015. 

Officially, it can be said that the Log Mod got underway in 2003 when GCSS-MC 
was established as an ACAT I program of record. This categorization put the Log Mod 
on an equal footing with the expeditionary fighting vehicle. Once established as a 
program of record, the Commandant of the Marine Corps put his endorsement on the 
program in January 2004 when he released a Marine administrative message, a personal- 
for message, and an all Marine Message (ALMAR) that emphasized the fact that the 
Marine Corps “...cannot improve the combat capability of the MAGTF without this 
LOGMOD” [63]. This message caused an increase in momentum on the part of his staff 
and in July 2004, the Deputy Commandant, Installations and Logistics launched the Log 
Mod Transition Task Force (TTF). After developing the six Log Mod initiatives (Log 
OA, Log C2, CSS R/R, MAGTF Distribution, ROM, and ROS), the TTF briefed the 
Expeditionary Force Development System (EFDS) Working Group who in turn formed 
an Assessment Group to write the directives to begin implementation. 

With the initiatives in place and the requirements detailed, it was time to select a 

software vendor. Unlike the Army, Navy, and DEA, the Marine Corps selected the 

Oracle e-business suite as their ERP of choice for the Eog Mod in August 2004. It has 

been stated by the Program Manager for GCSS-MC that Oracle was chosen “... because 

it satisfied the functional requirements more completely, provided greater flexibility for 

future needs, and demonstrated an understanding of the challenges” [63]. Shortly after 

73 



making the decision on the software, the hunt began for an integrator. The Marine Corps 
turned to Office of the Secretary of Defense (OSD) enterprise software initiative (ESI) in 
order to shorten the timeframe for acquiring an integrator. It was estimated that using the 
ESI save ninety days on the selection process. The integrator search began in November 
2004 and by April 2005 Accenture had been chosen to help make the Eog Mod a reality. 
Progress has been steady since the GCSS-MC team was formed with Oracle and 
Accenture and initial operating capability (IOC) for block one is expected in the Eall of 
2008. Eor Eiscal Years 2003 through 2007, the total cost for GCSS-MC is $171.7 mi llion 
[64], [65]. 

F. THE UNITED STATES AIR FORCE 

Being the technologically savvy branch that it is, it is somewhat surprising that 
the Air Force hesitated with their ERP program until post Y2K. Eike the other services, 
the Air Force also recognized in the late 1990s that the seven hundred plus legacy 
systems in the organization’s combat support IT portfolio were not capable of adequately 
tracking personnel and critical supplies. The ten detailed weaknesses of the legacy 
systems that the Air Force identified during that time period include [66]: 

• Eack of Authoritative Shared Data. 

• Eack of Easy Global Access. 

• High Operations and Maintenance Cost. 

• No Common User Interface (UI). 

• Insufficient Interoperability. 

• Hardware Dependency. 

• Insufficient Network Access. 

• Eimited Decision Support Tools. 

• Excessive Functional Dependency. 

• [Insufficient] Visibility. 

However, instead of immediately starting a project as was done in the Navy and 
Army, the Air Force followed the Marine Corps methodology and devoted themselves to 
defining the requirements and documenting the architecture to achieve the requirements. 
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1 . 


GCSS-AF 


In December 2001, the Air Force Material Command published the Operational 
Requirements Document for the Global Combat Support System - Air Force (GCSS-AF). 
The vision for GCSS-AF is a family of systems that has the ability to combine the 
information of the 23 combat support functional areas into an integrated environment to 
provide trusted data to all users. A portion of the GCSS-AF plan includes linking 
external entities such as the National Command Authority, the other service branches and 
allied and coalition partners to the integrated data to present a common operational 
picture to support joint operations. This vision is diagramed in Figure 3.20. 
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Figure 3.20. GCSS-AF High-Level Operational Concept Diagram (From: [66]) 

2. ECSS 

From the overarching framework of the GCSS, the Air Force subdivided out the 
logistics portion of the enterprise and titled it the Expeditionary Combat Support System 
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(ECSS). An exhaustive explanation of the ECSS system is not necessary because it 
copies the Marine Corps’ GCSS-MC program with the only difference being that it 
includes the wholesale level of supply. As was done by the Marine Corps, the Air Eorce 
formed an architecture for the ECSS which they titled the Eogistics Enterprise 
Architecture (EogEA) [67]. Also like the Marine Corps, the Air Eorce selected the 
Oracle e-business suite as their ERP of choice for the ECSS and signed an $88.5 million, 
multiyear contract with Oracle on October 25, 2005 [68]. Almost a year after awarding 
the ERP contract to Oracle, the Air Eorce broke out of the Marine Corps mold when they 
awarded a $627.8 million, multiyear contract on September 7, 2006 to the Computer 
Sciences Corporation (CSC) for integration services [69]. The ECSS is expected to be 
fully operational by September 2013 [70]. 
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IV. PROGRAM COMPARISON 


A. JOINT VISION 2020 

Released in June of 2000, Joint Vision 2020 is the document that the DOD is 
currently using to guide the future of America’s Armed Forces. The document builds and 
expands upon the principles established in Joint Vision 2010 to emphasize the changes 
that took place in the global environment between 1997 and 2000. However, the 
overarching strategy of full spectrum dominance first revealed in Joint Vision 2010 is 
carried forward in Joint Vision 2020 and it remains the goal for the DOD to work towards 
to meet and defeat its adversaries in the future. Along with full spectrum dominance, the 
foundational pillars of dominant maneuver, precision engagement, full dimensional 
protection and most important for the DOD’s ERP programs, focused logistics are carried 
forward in Joint Vision 2020 [71]. 

B. SEA POWER 21 

To incorporate the Navy’s capabilities into Joint Vision 2020, the Chief of Naval 
Operations published Sea Power 21 in October 2002. 


SEA POWER 21 

Sea Shield 



Sea Basing 


Figure 4.1. Sea Power 21 (From: [72]) 
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Sea Power 21 is the name of the Navy’s strategic vision for how it will organize, 
integrate, and transform in the coming years to meet the requirements of Joint Vision 
2020. Like, Joint Vision 2020, Sea Power 21 is made up of foundational pillars that work 
together to achieve the Navy’s overarching strategy and correspond to the pillars of Joint 
Vision 2020. In Sea Power 21, the foundational pillars are Sea Shield, Sea Strike and Sea 
Basing. Sea Shield is the Navy’s version of full dimensional protection and Sea Strike 
covers dominant maneuver and precision engagement. 

1. Sea Basing 

Sea Basing ties in with focused logistics and is important because the objective of 
the pillar is to place at sea, a network of platforms that include strike ships (aircraft 
carriers, frigates, destroyers, etc.), combat logistics force ships, and maritime 
prepositioning ships that are operated by the Military Sealift Command. Modem 
technology that facilitates the networking of these different platforms with 
communication systems and sensors is overcoming the traditional view that forces at sea 
have a difficult time with interoperability due to dispersion. Rather, the netted force of 
ships can be viewed as an operating platform from which the joint and coalition 
commander can employ “...offensive and defensive firepower, maneuver forces, 
command and control, and logistics” [73]. 

There are several reasons the Navy has placed Sea Basing as an integral part of 
the Sea Power 21 vision. The first reason is that with bases at sea, there is a force 
available to rapidly respond to crises and project power throughout the world. Secondly, 
a reduced footprint ashore can be achieved by leaving the command and control (C2) and 
logistics assets aboard ship. The third reason is it has been getting increasingly difficult 
for the U.S. forces to operate from foreign soil. Recent examples of this dilemma include 
the trouble the U.S. had with Turkey in Operation Iraqi Freedom and the withdrawal of 
the American military presence form Saudi Arabia. Therefore, by deploying forces from 
the sea, the U.S. can avoid the political and military obstacles that might obstruct the 
establishment of land bases. Lastly, and most importantly, as a concept. Sea Basing 
requires a substantial Navy. Thus, it provides the Navy ammunition in the fight for the 
precious tax dollars that all the services are desperately vying for. 
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2. Joint Logistics 

To effectively compete for these tax dollars in the post Goldwater-Nichols 
military, a demonstration of how a capability is applicable in the joint arena has become 
paramount. Consequently, the Navy has looked outside of itself, and incorporated the Air 
Force, Army and the Marine Corps into Sea Basing. For the Air Force, Sea Basing 
envisions “... Air Force unmanned combat vehicles surging to sea bases rather than 
bedding down ashore” [73]. The integration of the Army and Marine Corps is more 
extensive. It is proposed that the Sea Bases can serve as assembly areas where the Army 
and Marine units deploying into a combat theater can be married up with the larger 
weapons systems that are carried by sea. Upon the arrival of the soldiers and Marines on 
ship, the weapons systems can be selectively retrieved and assembled prior to embarking 
the troops off the ship and into combat. Not only are the Sea Bases important to the 
Army and Marine Corps for retrieval of equipment, it is also anticipated that they will be 
the source for the critical sustainability packages of supplies the ground forces require as 
they conduct combat operations. Historically, the Navy has always filled this role for the 
Marine Corps but Sea Basing emphasizes the importance of this capability to reduce the 
Marine Corps footprint ashore. The added idea of having ships operate as assembly areas 
for Army soldiers is what makes Sea Basing a departure from traditional operational 
doctrine [74]. 

The technology that will make the Sea Bases capable of meeting the requirement 
for an assembly area and supply point is twofold. First, the ships must have the latest 
advances in inventory management and automated material handling systems so that they 
can locate, identify and retrieve the necessary equipment while remaining at sea. Second, 
the Navy and its ships has to have a logistics system that incorporates modern supply 
chain management initiatives like “Just In Time” supply. Total Asset Visibility (TAV) 
and In-Transit Visibility (ITV) as well as be integrated with the Air Force’s, Army’s, and 
Marine Corps’ logistic systems so that it can make the vision of Sea Basing a reality [74]. 

C. TROUBLED APPROACH 

The U.S. National Command Authority (NCA), the separate service component 
Secretaries and Joint Chiefs of Staff are trusting that the integration of the separate DOD 
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ERPs at some point in the future will deliver the warfighting support potential resident in 
the strategic documents of Joint Vision 2020 and Sea Power 21. Unfortunately, this is 
the only thing that can be hoped for because of the separate approaches that were taken 
toward ERP when the projects first got started in the late 1990s. During this period, the 
DOD should have established a central ERP office and the DOD in its entirety could have 
been defined as the enterprise to be covered by a single ERP. 

1. Ideal ERP 

Theoretically, one ERP for the entire DOD ought to be possible because the 
separate services logistically function in the same way. Eor example, each branch of the 
military has aircraft. All aircraft require parts and maintenance. The ideal situation 
would be one ERP controlling the processes for the supply of parts and maintenance on 
aircraft across all the services. This would allow service members with similar functional 
backgrounds to work side by side in the joint operational arena without any concern for 
knowledge barriers resulting from disparate process comprehension. Eacilitating an 
environment where Air Eorce supply clerks could order parts for Army helicopters. 
Marine jet mechanics could work on Air force jets and so forth. Instead, the best 
outcome is the separate ERPs can be connected at some point in the future to provide an 
integrated view of the entire DOD’s data. While not perfect, the envisioned solution is a 
drastic improvement over the current operating environment which has soldiers, sailors, 
airmen and Marines using unique logistics systems with no integration. The severe 
problem with this environment surfaced recently in Operation Iraqi Ereedom where 
“...platoons were unable to locate the nearest MRE’s (Meals Ready to Eat), spare parts 
were difficult to obtain driving multiple re-orders and unidentified supplies were 
stockpiled at significant cost without contributing to warfighter effectiveness” [5]. 

The first-class corporations that have successfully transformed their organizations 
using ERPs are those that identified their common core business functions and aligned 
their ERP around those functions to maximize their potential. Notionally, this should 
have been possible within the DOD. The entire DOD has common characteristics which 
include personnel, equipment, and facilities. Each one of these characteristics has 
common data points as well. Eor example, all personnel have a social security number. 
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age, gender, rank, etc. All equipment has a dimension, part number, national stock 
number, name, etc. Facilities have an equal number of common characteristics. The core 
business function of the DOD involves leaving the facilities and transporting the 
personnel and equipment around the world to engage foreign adversaries. In this 
endeavor, there are common transportation platforms as well as a universal support 
structure that supplies the military both at home and abroad with the primary example 
being DLA. The similarities between the service components do not end at their business 
functions. A review of the reasons discussed in Chapter III for each of the services’ and 
DLA’s choice to initiate an ERP project reveals that collectively they are facing the same 
problem: outdated business procedures and processes running on antiquated software 
systems. 

By focusing on their commonality vice their differences, the multiple sectors that 
form an entire organization can achieve what is known as conceptual unity. The proof 
that conceptual unity can be achieved by any organization no matter how large is 
demonstrated by the nation of Singapore. Studies of the country have shown that 
“...Singaporeans as a whole understood the vision and mission of Singapore” [5]. The 
embracing of conceptual unity between the government and industry has led to the label 
“Singapore Inc” [5]. Disappointingly, because the DOD CIO that was appointed as a 
result of the Information Technology Management Reform Act (ITMRA) did not push 
conceptual unity at the outset of the ERP undertakings and because the funding for the 
ERP acquisitions resides at the service level, the services are left working toward the 
same objective in different ways. 

2. Adopt Proven Methodologies 

In industry, it has been proven that integrating ERPs of separate organizations is a 
much easier task than integrating legacy stovepiped systems. This fact is evidenced by 
the trend of companies migrating from ERP to ERP II that was discussed in Chapter II. 
While, it is not ideal that the separate service components and DEA are working on their 
ERP projects individually, it is the reality of the situation. Thus, the best that can be 
hoped for is the successful implementation of the current projects and the future 
integration of these projects. The numerous examples from industry (also in Chapter II) 
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where ERP integration has been a proven recipe for success are the reason for the trust 
that the DOD has placed in the future interoperability of the separate ERPs. However, to 
attain the vision of an ERP enabled and integrated logistics environment, the service 
components are going to have to abandon certain practices common to the military and 
embrace the successful ERP methodologies verified in industry while avoiding the ERP 
pitfalls. 


3. Past Mistakes 

Chapter II presented pilot projects as a beneficial way of testing the organizational 
redesign that an ERP entails prior to translating the redesign across the entire 
organization. It is a risk reducing approach because a pilot proposes easy termination if it 
is determined that the project is not going to meet expectations. Eor an organization that 
is adverse to risk like the U.S. Navy, this seemed like the perfect route to success when 
they started the four ERP pilot projects in 1998. However, the initial framework that the 
Navy set their pilot programs up in steered the project toward trouble from the start. 

Technochange experts recommend that only one or two pilot projects be initiated 
[33]. The first major mistake of the Navy was to go against this recommended number of 
pilots. Instead of one or two, the Navy started the four pilots outlined in Chapter III. 
Each of the pilots was independently headed by the Commanders of the separate 
SYSCOMS and no manager was put in place to oversee the projects as one initiative. 
The choice to not establish a single point of contact to supervise the Navy’s ERP program 
does not follow the principles for transitioning to an ERP that have been set by industry 
and technochange guidance which advocates that a “strong man” has to be part of the 
effort. While the Commanders of the separate SYSCOMS are high ranking naval 
officers, when comparing the Navy to a corporation, they do not equate to the Chief 
Operating Officer and can thus be considered middle management. Eurthermore, the 
spreading of responsibility for a high risk project amongst several leaders is a common 
practice of the Navy headship. The purpose of the practice is to avoid a single agency 
head being identified or held accountable for cost overruns or a project’s failure. It is 
evidenced by the manner in which the Navy handles its shipbuilding budget. The current 
headlines state that multiple shipbuilding programs have repeatedly busted their budget 
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and the “...House Armed Services Committee wants to know who to blame” [75]. This 
desire by Congress to find someone to be responsible for the shipbuilding program has 
led to an amendment to the 2007 Defense Authorization Act that requires the Navy “top 
brass” to take responsibility for it. 

Unfortunately for the Navy ERP program, there was no such amendment looking 
out for its best interest back in 1998 and the four pilots began with no overarching 
structure to resolve differences and steer the project in a unified direction. In 
technochange and transformational change efforts, a “strong man” that exhibits strong 
leadership is critical for success. The literature surrounding both types of change states 
that solid leadership is an indispensable element that must be present to move the change 
process forward. Without “... new leader[s], great leader[s], or change champions” it is 
highly probable that the intended transformation will fail [76]. Continuity of these 
change champions is also an essential element to see the change through to completion. 
The type of transformational change that an ERP brings about takes time. Military 
officers in key positions to influence major change only stay in those positions for two to 
four years. This rotation schedule can kill the momentum of an ERP project if the 
follow-on leader does not place the same amount of emphasis on the program that the 
previous leader did. 

The Navy ERP pilots did not have a “strong man” and it took a heavy toll on the 

program because the functional overlap between the pilots was ignored by the 

management teams [77]. The overlap is a result of the fact that the SYSCOMS have a 

tremendous amount of commonality and their leadership refused to acknowledge this 

fact. Eor example, as was stated previously, military equipment has common 

characteristics such as national stock number, part number and nomenclature. All the 

pilots dealt with military equipment in some form or other and the individual pilot 

leadership chose to ignore this commonality vice embrace it. “Instead, the Commanders 

of the SYSCOMS and the project managers directing the projects evolved the pilots into 

programs and shifted the emphasis from a trial to a project which was to be completed 

and implemented. A competition ensued over which command could get their ERP up 

and running first. To remain on schedule, inter-project cooperation was discouraged 

which led to a lack of formalization on the format of common data and processes that 
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should be followed in the aeeomplishment of tasks” [77]. Without an overarehing 
leadership strueture to manage the pilots, there was no way to foree eooperation and the 
pilots drifted further and further apart in their approaehes. 

The Navy eontends that four pilots were started beeause it was believed that doing 
one implementation for all the SYSCOMS was too large of an undertaking to be 
sueeessful and rationalized the pilots by asserting that they were designed solely to test 
the funetionality of an ERP within the Navy [77]. Having multiple pilots was a way to 
reduee the risk and gave eaeh of the pilots a better ehanee for sueeess. It is true that 
pilots are a good way to reduee risk beeause they provide users “hands-on” experienee 
with the new proeesses and allow for feedbaek on where improvements need to be made 
before the pilot is expanded to other parts of the enterprise. However, it ean be 
eontended based upon the way the Navy handled the shipbuilding prior to 2007, that four 
pilots were started beeause it provided for a spread of responsibility in the event that 
someone was going to be held liable for eost overruns or failure. Had only a single pilot 
been started at one of the SYSCOMS, it would have demonstrated how the seleeted ERP 
(SAP R/3 in the ease of the Navy’s pilot programs) would handle the eommon data and 
proeesses of all the SYSCOMS. Better yet, all the SYSCOMS eould have sent 
representatives to work on a single pilot to negotiate the proper format for the eommon 
data and proeesses. 

In industry, a eonglomeration of representatives from the different funetional 

areas that eome together and are responsible for eonfiguring an ERP are known as a eore 

team. A solid eore team that has both business and teehnieal knowledge has proven to be 

a vital faetor to suceessfully eonfigure an ERP [78]. Then again, this arrangement would 

have required a single high ranking representative from the Navy to hear out the separate 

arguments within the eore team and make determinations in the best interest of the Navy 

as a whole. Regrettably, all of the senior Navy personnel and projeet managers were 

unwilling to leave their roles as managers to take on a role as a leader. There is a 

differenee between a manager and a leader beeause “management’s mandate is to 

minimize risk and to keep the eurrent system operating. Change, by definition, requires 

ereating a new system, whieh in turn always demands leadership” [76]. Eurthermore, it is 

probable that if only one pilot had been started instead of four and it was ruled a failure or 
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had some cost overruns, nobody would have been held accountable because that is the 
purpose of pilots. They are by their very nature tests of whether a proposed solution is 
viable or not. The ingrained protectionist attitude and competition between peers 
exhibited by the pilot’s management teams led to a pilot structure that prevented any 
possibility for success and deplorably wasted a huge sum of taxpayer’s money in doing 
so. “Problems with the structure and the commonality of the pilots was addressed with 
the program managers but it was judged to be mutinous commentary” [77]. 

The decision to use multiple pilots instead of a single pilot was a big mistake but 
it was not the only mistake made in the early stages of the Navy ERP. Using a 
prototyping approach also proved to be a hazard to the project because the user 
involvement led to an attempt to align the prototype with the old business processes 
which is ERP pitfall number one: overcustomization. Private companies that had core 
teams who made attempts at layering their old business processes within the mold of an 
ERP discovered it is a fruitless job. Eegacy systems allowed for process customization 
because they were coded according to the processes of individual industries. The 
processes were in existence before the legacy system came about and the legacy system 
came into being as an automation tool for those processes. This is fundamentally 
different than an ERP which is a template that has certain structural elements that should 
not be changed. Those elements exist to help organizations implement standard business 
processes across the spectrum of operational divisions. The templates also make it 
impossible to avoid a revision of processes during implementation. If the users who are 
involved in the prototype are reluctant to re-engineer business processes to conform to 
the ERP, the implementation of the ERP runs a high risk of failure [79]. 

All of the service components within the DOD can be defined as mechanistic 

organizations. “The ideal model of the mechanistic organization is one of efficiency and 

predictability, hierarchically ordered, in which planning and decisions occur at the 

strategic apex and are implemented at lower levels” [80]. A hallmark of such an 

organization is a culture that resists change. In essence, the service members who are in 

the Navy are the Navy and undeniably part of the culture. The ideal model is an exact 

description of the best way to bring about change in a mechanistic organization. Drive it 

from the top. If members of a mechanistic organization are not forced to change by the 
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leadership, they will naturally resist it because of the culture. The level of commitment 
the Navy leadership extended toward the ERP pilots has already been addressed. Given 
the context, when asked to make concessions to the ERP’s way of doing business, the 
users guiding the prototypes in the pilot programs said no and there was nobody there to 
make them change their minds [77]. Of course, implementing an ERP which has been 
designed to operate in the corporate world where money does not expire at the end of the 
fiscal year or have numerous policies dictating how it is spent does have its inherent 
challenges. Also, the ERPs of the late 1990s were not as flexible and did not support the 
open architecture standard that they do today. Nonetheless, it was not these challenges in 
their entirety that led to the weaknesses of the Navy’s pilots. Could it be argued that they 
were a contributor? Definitely! Yet, a larger contributor to the shortcomings of the pilots 
was the inability of the users to change and a lack of commitment by the leadership to the 
proposed change [77]. 

At the conclusion of the pilots, the U.S. Government Accountability Office 
(GAO) categorically ruled the pilots a failure. They declared that what had been created 
was “...four more DOD stovepiped systems [systems incapable of interoperability that 
serve a single function] that did not enhance the DOD’s overall efficiency and resulted in 
$1 billion being largely wasted” [45]. The Office of the Under Secretary of Defense for 
Acquisition Technology and Eogistics defended the pilots arguing that “The Department 
views the pilots as successful, exceeding initial expectations, and forming the foundation 
upon which to build a Navy Enterprise solution” [45]. As presented in Chapter III, the 
Navy is currently working on the integration of the work completed on the pilots to create 
a converged ERP solution. The GAO contends that by creating a converged solution, the 
Navy is essentially starting their ERP over [45]. To implement the Navy’s converged 
ERP, the GAO also contends that is going to take another $800 million and it will not be 
operational until 2011 [45]. 

4. New Plan 

In 2004, the Navy published an integration white paper that outlines the 
architecture for the converged solution [47]. The information contained within that paper 
highlights the problems the Navy created for itself by using multiple pilots. It states, “If 
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the Navy were implementing with no existing ERP solutions, the implementation strategy 
would be different, but the existing projects demanded careful architectural planning in 
order to minimize re-work and reduce risk to the fleet” [47]. It further states, “The Navy 
initiated multiple pilot projects in 2000, and the pilot projects were successful, but they 
provided localized solutions as opposed to an integrated solution for the Navy’s operating 
forces (i.e. the fleet)” [47]. Lastly, it states, “Adoption of common business processes 
across maritime and aviation, which requires re-work in one or both solutions” [47]. This 
sentence emphasizes the fact that by having separate processes for the same tasks, the 
Navy’s ERP is going to have to be re-worked. All of these sentences are in a document 
produced by a contractor working for the Navy and they still can not evade the truth that 
by using multiple pilots with no long term planning and cooperation to integrate the 
pilots, a problem resulted and a lot of money and work is going to have to go into fixing 
it. 

It is clear from the GAO report on the Navy’s pilots [45] and from the Navy’s 
own documents that the way the pilots were structured created problems. The questions 
that surfaces from the debate between the GAO and Navy are: 

• How much did the pilots actually cost? 

• What functionality will the converged ERP deliver? 

• When will it be complete? 

In the case of this debate, it is clear that the two organizations are taking very 
different positions and the real answers to these questions most likely lie somewhere in 
the middle. Therefore, the DOD’s Business Transformation Agency (BTA) was 
consulted to provide and independent third party analysis on the issues. The GAO stated 
that the pilots cost $1 billion [45]. Contrarily, the Navy says that “35% or 350M of the 
$1B referred to in the draft was for investment in the development of the pilots, while 
55% was for operating and support expenses, and the remaining 10% for the early 
definition of the converged Navy ERP solution” [45]. Eor the period through Eiscal Year 
2006, the BTA is advertising that the Navy ERP cost $859.7 million [81]. This figure 
supports the argument that to date, the Navy has spent close to a $1 billion on the ERP 
including the pilots. The BTA further supports the GAO’s prediction that through 2011 
the Navy ERP will cost another $800 million. Including the Eiscal Years 2007, 2008, and 

87 



2009, the BTA has a figure of $683.1 mi llion. Carrying the trend out two more years to 
2011 validates the GAOs claim that the cost will be somewhere near $800 million. 

Functionally, the converged system that is in development is similar the Army’s 
Logistics Modernization Program (LMP). When the convergence is complete the Navy 
will have an ERP to cover the wholesale level of supply. 


NALCOMIS OMA 


NALCOMIS OOPMA 



HSMS 


One Touch 


rriMP 



Materials 

r ) Management 


SPS 

DAMIRS** 

CCR 

FLIS 

STARS FRS 
DAAS 
DDRS 


NALCOMIS OMA 


NALCOMIS OOMA 


Plant 
Maintenance 




DTS 
DCPS 
One Pay 
MOCAS 
DDRS 
STARS FRS 
WAWF 

Management oaas 

DC AS 


Financiai 


Workforce 

Management 



DIMHRS** 

DCPS 

C Manugiatica ') 


Wholesale 

Supply/APS 


**WHEN AVAILABLE 

DoD Interfaces 
C Bott^Ons ^ 


Figure 4.2. Navy ERP Interfaces (Prom: [4]) 

Por the retail portion, the current plan calls for the legacy systems (UADPS, NAECOMIS 
OOMA, CAV, One Touch, etc.) to remain in place and be interfaced to the ERP. This 
relationship is depicted in the materials management portion of Pigure 4.2. The ERP 
“deployment sites include fleet maritime and aviation intermediate-level maintenance 
activities ashore and major Navy systems commands and their associated warfare centers 
and field activities” [82]. In the integration white paper, there is a mention that “The 
Navy plans to deploy SAP on its warfighting vessels” which can be considered the retail 
level for the seagoing service. However, there is no formal program in place like GCSS- 
Army or GCSS-MC. Por the time being, the focus is integration of legacy retail systems 
into the wholesale ERP. 
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The timeline of 2011 established by the GAO is vague so the BTA was referenced 
to confirm what the actual timeline is for the Navy ERP. Based upon what is being 
publicized by the BTA, the Navy ERP will reach full operational capability (EOC) in the 
Spring of 2013 [81]. 

D. A DIFFERENT TACTIC 

Since the Navy ERP is functionally similar to the Army EMP and both programs 
got underway in the late 1990s using the same SAP solution, it is important to analyze the 
reasoning behind the different approaches. The method the Army chose for their 
technochange was riskier than the Navy’s because they did not elect to go with a pilot or 
prototype. Instead, the Army selected the “...traditional design first then implement 
approach” [33]. This approach is preferred by the companies implementing an ERP 
because it is much less time consuming than the prototyping approach [33]. It is riskier 
because the expected results of the ERP customer are not often achieved and the 
organizational problems with the software that stem from the lack of user involvement 
are numerous. This reality was thoroughly documented in Chapter II. Nonetheless, the 
Army was willing to take this risk primarily because it was the recommended path to 
follow by their integrator (CSC). Integrators of ERPs recommend the design then 
implement approach to corporations because a speedier approach equates to a less costly 
venture. In the corporate world, the bottom line is the top priority and companies are not 
very receptive to lengthy change proposals that can quickly compound cost and run a 
high risk of failure. 

I. Organizational Distinction 

A speedier approach was attractive to the Army for several reasons. Eirst, the 
Army did not have multiple organizations like the Navy responsible for the procurement 
of supplies. Unlike the Navy’s aviation and a maritime branch, the Army has a single 
organization (the Army Material Command) responsible for its supply chain. Secondly, 
the Army liked the speedy approach because it is capable of overcoming several kinds of 
resistance. The AMC leadership recognized its role as a mechanistic organization and 
understood that the resistance to the ERP would be high. They also recognized their 
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extensive power over the organization and were willing to use it. Wielding power to 
force people to accept change is known as explicit coercion. It can be a very powerful 
tool to use in mechanistic organizations where change is never popular. The downside of 
using explicit change tactics is that they can potentially leave the users at the lower levels 
disgruntled with the change initiators [83]. If explicit coercion is going to be used, it has 
to be used quickly in order to defeat the resistance that is common in the BPR 
Organizational Life Cycle of Chapter II. 

The third reason the Army elected to take the riskier approach was because their 
dissatisfaction with their legacy logistics operating environment was much higher than 
the Navy’s. In change theory, there is a formula which states: “Amount of Change = 
(Dissatisfaction X Model X Process) > Cost of Change” [84]. A summary of the formula 
is that the dissatisfaction of the influential leaders with the status quo must reach a level 
that the leaders decide that there is no choice but to change. This dissatisfaction along 
with a model of the future state of the organization and the process for how the 
organization will achieve that end state can generate enough power to outweigh the cost 
of making a change. The level this power needs to reach is exceptionally high because 
the cost of change, which is measured by resistance to change, is significant. For the 
Army, the dissatisfaction with their logistics processes was at an all time high in the mid 
1990s following the end of the first Gulf War. In that engagement, the Army feared that 
they wouldn’t have the supplies they needed so they sent everything into theater and 
created the “iron mountains” of unused equipment discussed in Chapter I. It was 
reported that of the 42,000 containers that were sent overseas in support of the operation, 
the Army had to open 28,000 of them just to verify their contents [85]. Despite the 
proliferation of supplies, the Army had a remarkably hard time getting equipment to the 
units that needed it, when they needed it and where they needed it. This struggle was so 
profound that it led to a dissatisfaction level that made the Army more willing to take a 
riskier approach to their technochange. Contrarily, the Navy did not have the same 
experience in the first Gulf War because the Navy continually operates as a forward 
deployed force in peacetime and in war. When the ships (retail supply level) pull out of 
their homeports, all the supplies they need are onboard or they will be replenished while 
underway. For the Navy, a war in the Gulf simply meant it had to change the position of 
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the majority of its ships and concentrate them in one area. It need not worry about trying 
to make a logistics system that was designed to support home based forces function 
across the globe. The Army did and experienced a large amount of pain in doing so. For 
that reason, they were more receptive than the Navy to the advice of their integrator to 
make their first priority in their ERP the reengineering of their business processes [3]. 

Lastly, the Army took the riskier approach because as an organization in the late 
1990s, the Army was more amenable to the inherent risk in change than the Navy. The 
substantiation for this statement is the Army’s three training centers at Fort Irwin, 
California; Fort Polk, Louisiana; and Hoenfelds, Germany. During the mid 1990s, the 
training conducted at these three bases encouraged constructive conflict and decision 
making at all levels. It also expected straight talk between superiors and subordinates 
about what went wrong and what went right during training evolutions. These 
discussions along with thorough after action reviews of individual and group 
performance created dissatisfaction with the status quo at all levels of the Army. The 
training experience as a whole internalized a state of mind that was a departure from the 
mechanistic way of thinking in all the soldiers who went through it. Soldiers began to 
think of radical new ways to solve problems individually and as groups and the different 
thought process restored the Army’s “cultural vitality” [86]. The training program was so 
progressive that it was “...studied by the chief education officers at Shell, Sears, 
Motorola, and GE, and by senior delegations from every country in Western Europe, 
Russia, and most nations of Asia, Latin America, and the Middle East” [86]. 

2. The Payoff 

Nobody can make the claim that the Army has had a flawless ERP 
implementation. In May of 2004, the GAO uncovered problems with the LMP 
“including such issues as failure to follow necessary disciplined processes, lack of 
financial system integration, and system deployment slippage” [1]. Nevertheless, the 
level of criticism directed at the Navy ERP program is much higher because when the 
systems are put side-by-side, the Army has made more progress in less time and at 
substantially less cost by choosing the “design then implement” approach. Both systems 
perform the same function for their service components. Yet, since it initiation through 
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Fiscal Year 2009, the Army’s LMP cost stands at $1.06 billion [87]. For the same period, 
the Navy’s ERP total cost comes to $1.54 billion [81]. The LMP went live in July of 
2003 [87]. In October, 2007 the Navy’s converged solution is scheduled to go live. Four 
years behind and close to $500 million more for the same system. 

E. CHANGE OR DIE 

DLA’s BSM is similar to the Army’s LMP in that DLA also chose to follow the 
“design then implement” approach and has found success with it having achieved LOG in 
2006. Taking the comparison beyond this top level is not worthwhile because the BSM 
does not serve the same function as the LMP and the Navy’s ERP. The BSM is not 
concerned with the acquisition of major weapons systems and the wholesale level of 
supply for those systems. Rather, it was acquired to secure DLA’s position as the 
consumable supplier to the service components. 

In the late 1990s, corporations such as Wal-Mart were creating value and cutting 
cost by eliminating central purchasing departments. Removal of such intermediary 
departments was made possible through the sharing of retail information directly with 
suppliers [88]. When viewed from the corporate perspective, DLA is a central 
purchasing department for the consumable parts the DOD requires. Thus, when the trend 
went toward ERP in the Army and the Navy, DLA recognized the possibility that if they 
did not provide their customers (the service components) a modern IT system to plug 
their ERPs into, the customers could bypass DLA and interface directly with the vendors 
for consumable parts. Such a scenario would eliminate the need for a DLA. This 
prospect gave birth to the BSM and the BSM along with the agency’s ERP II initiatives 
has secured DLA a position in the future of DOD logistics. 

F. THE BENEFICIARIES 

From the Army, Navy and DLA ERP projects, both the ERP vendors and 
integrators gained a large body of knowledge about how to structure an ERP for the U.S. 
military. This knowledge has been applied to the ERP vendors’ military templates and 
the Marine Corps and Air Force is now capitalizing on the lessons learned and 
investments made in the Army, Navy and DLA programs. For the Marine Corps, it took 
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the supply chain problems of Operation Iraqi Freedom I to drive the dissatisfaction with 
the current processes to a level where the Corps’ leadership was forced to remedy the 
situation [89]. After deciding that the time had come to adopt an ERP, it appears that the 
Corps absorbed the lessons from the Navy pilots because the highest ranking Marine (the 
Commandant of the Marine Corps) is taking the position of “strong man” for the 
initiative. Furthermore, the Corps’ transformation plan of focusing on people, processes 
and technology demonstrates a clear understanding that managing the change that people 
are going to experience as a result of the ERP is as important as the ERP itself. A 
commitment to changing business processes is also equally important because to work 
within the confines of an ERP template, an organization can not hold on to old processes. 
Easily, by planning for the GCSS-MC to rely on DEA’s NIMS system, the Army’s EMP 
and vendors to manage the majority of the Marine Corps material, the Corps is 
demonstrating a profound understanding of the capabilities that modern supply chain 
management practices can deliver. 

The Air Eorce intentionally waited to see how the ERPs of the other service 
components and DEA were working before making any decisions on the topic [90]. It is 
apparent that the Air Eorce liked what they saw in GCSS-MC because they are following 
an implementation plan that emulates the Marine Corps’. Eike the Marine Corps, the Air 
Eorce has chosen the Oracle e-business suite ERP and has also elected to have a single 
system handle the entire supply chain from end-to-end [66]. It is an approach that has 
paid off for the Air Eorce because through Eiscal Year 2009, the ECSS system is 
projected to cost $694 million [70]. By waiting on the results of the other ERP projects 
and making the decision to have a single system control the retail and wholesale levels, 
the Air Eorce is projected to have a more capable system for a little more than half the 
cost of the Army’s EMP and a third of the cost of the Navy’s ERP. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSION 

ERP in the DOD started in order to achieve compliance with the Federal Financial 
Management Improvement Act of 1996 (FFMIA) and fix the supply chain problems of 
the first Gulf War. An organization with a long-established “push” supply process was 
looking to institute “pull” supply processes. 




^Pull ^ 

Active 

Resources scheduled 
Logistics anticipates 
Less efficient 
Based on estimate of 
Consumption due to 
Operational tempo 


Reactive 

Resources requested 
Unit anticipates 
More efficient 
Based on actual 
consmnption rate 



Figure 5.1. Push Vs. Pull Distribution (From: [91]) 

“Pull” supply chain management practices operate by the principal that the production 
and distribution of supplies is a single process and tremendous efficiency gains can be 
had by keeping inventory continuously moving. Waste is created when supplies are kept 
in storage. Therefore, the chain of events that must take place to get finished goods into 
the hands of the end users has to be integrated so that there is a minimum amount of 
storage at any stage. Automated Information Systems (AIS) that share demand schedules 
and production completion dates with every member in the supply and distribution 
pipeline are a critical enabler of “pull” logistics. For most organizations that operate a 
according to “pull” principles, the AIS of choice is an FRP [10]. 
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Following the first Gulf War, the DOD began to recognize the enormous gains in 
efficiency that private sector organizations were achieving with “pull” supply chain 
management practices and ERP systems. However, it took the FFMIA mandate and the 
vision of “focused logistics” to encourage action by the Navy, Army, and DLA. This 
thesis examined the ERP programs of the Navy, Army, and DEA as well as those of the 
Marine Corps and Air Eorce. Additionally, an analysis of the ERP experiences of 
corporate organizations was conducted so that a comparison could be made between the 
most successful ERP implementations of the public sector and the DODs 
implementations. This comparison revealed that the corporations that are able to 
maximize the capabilities offered in an ERP are the ones that acknowledge and address 
the ERP pitfalls outlined in Chapter II and embrace conceptual unity amongst all the 
divisions within their organization. By embracing conceptual unity and establishing a 
true ERP “strong man”, the most successful organizations are able to place the ERP in the 
highest possible context and integrate all departments so that data can be matched, cross- 
matched, and shared throughout the organization. Placing the ERP as a top-level 
initiative eliminates wasteful duplication and provides the organization a complete 
enterprisewide application. 

Without an overarching framework to guide the DOD as an enterprise toward a 
single ERP implementation, the Navy, the Army, and DEA started their individual ERP 
programs. Not recognizing the common core business functions between the service 
components and DEA, the three organizations abandoned conceptual unity in favor of 
distinctive approaches to the same problem with each choosing to define itself as the 
enterprise. The Navy further subdivided itself and defined each individual systems 
command as an enterprise. By not acknowledging the fact that the organizations that 
have had the most success using an ERP are the organizations that put the system in the 
highest possible context, the DOD missed the opportunity for an optimal solution. At a 
time when “focused logistics” was in print as the vision for the future of DOD supply 
chain management, the benefits of a single ERP running all of the Department’s logistics 
data should have been apparent. Unfortunately, this foresight was lost amongst the 
traditional competition between services for individual identity and a funding plan that 
put money at the service component level and left it up to the individual entities to figure 
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out the best way to implement an ERP. There is a ray of hope that the DOD is realizing 
the mistake it made with the recent example of the Marine Corps and Air Force using the 
same approach and receiving tremendous benefit from doing so. Nonetheless, even with 
the Marine Corps and the Air Force using the same approach and the same ERP platform, 
when all the service components have their systems fully operational, the DOD is going 
to have five stovepipes that have to be integrated to realize “focused logistics” [4]. 

B. RESEARCH QUESTIONS 

1. What is an ERP? 

An overview of what exactly an ERP system is and how it is implemented is 
provided in Chapter 11. The analysis presented in Chapter II leads to the conclusion that 
despite the fact that the DOD missed a notional opportunity for an optimal ERP, the 
decision to use ERPs instead of custom software to transform the DOD business systems 
was the right choice. 


a. Software Product Lines 

On average, ninety percent of custom software projects in the DOD are 
failures. Acquiring software that has been developed using a product line architecture 
has a proven track record of achieving success in the DOD more than ninety percent of 
the time [92]. Software that has been produced using a product line architecture has a 
base platform from which product lines are built to capture the domain specific 
components of particular market sectors. For example, with an ERP, the base platform is 
the generic template that holds the core functionality of the system. On top of the base, 
domain-specific product lines such as a commercial line, a military line, and an 
educational line are built to market to those specific market segments. Taking the 
architecture one step further, each specific customer adds additional features to their 
product to meet specific needs that are not in the product line. 
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Figure 5.2. A schematic view of an ERP product line (After: [93]) 

The principal benefit of using product line software is that it allows for “...significant 
cost and effort reductions through large scale reuse of software product assets such as 
architectures, components, test cases and documentation” [93]. Software product lines 
are able to reuse software product assets by building off the core. In the case of an ERP, 
the core is the base template from which all product line templates are built. The cost of 
developing and maintaining the core is spread across all the product lines which translate 
into lower cost for the individual customers. Another benefit of the product line 
architecture is quality is improved because defects in the core only have to be fixed once. 
As soon as a defect is found and fixed, all the product lines receive the benefit of an 
improved core. 

A final benefit of software product lines is that custom component 
additions developed for individual customers can be used by all the customers in the 
product line who find the component beneficial. This is important in the context of the 
DOD ERPs because if the German military invest heavily in an ERP feature that is 
important to them, but, that feature is also applicable to the U.S. customers in the product 
line, then, it does not cost anywhere near what it would cost if a single customer had to 
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bear the burden alone. Once a custom feature is developed that has a wider customer 
base, it can be placed in the product line (the military product line in this case) and the 
other customers can purchase it for a fraction of what it cost the original customer. If a 
feature has an even wider audience, then it can be rolled into the core and all the product 
lines can profit from it. Furthermore, the customers of a product line can collaborate to 
have a feature developed for everyone in the product line and share the cost of that 
feature. If each customer were using custom software that does not follow a product line 
architecture, this would no be possible. They would each have to pay for whatever 
features they want separately. This is one of the problems with the legacy systems 
identified by the Army in Chapter III (lack of cost sharing). 

b. Established Architecture 

Requirements definition and system design are the first two stages of a 
software development project. Software design experts confirm that “Leveraging known 
solutions [in the design stage] minimizes the risks that an application will fail due to an 
inappropriate architecture” [93]. This is the second reason that ERP was the right choice 
for the DOD’s problems with supply chain management. ERPs have an established 
software architecture that has a demonstrated track record of success integrating business 
process to deliver the right products to the right place at the right time while at the same 
time accounting for the transactions properly and not having accounting functions slow 
the whole process down [94]. A look back at Eigure 3.9 reveals that the business 
processes that DEA was looking to capture with their ERP are the identical processes of 
any intermediary distributor. Such organizations buy materials in large lots and sell in 
smaller lots to users whose operations do not justify large lots. Erequently, distributors 
act as brokers and have materials ordered by customers shipped directly from the 
manufacturer when the item ordered is not held in inventory [10]. By changing the 
wording and the pictures in the figure, the business processes of amazon.com or any other 
distributor would be depicted. Consequently, looking to industry to find out what IT 
systems were helping some of the “best in the business” perform the distribution function 
is the smartest thing DEA could have done. 
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2. 


By Industry Standards, What is the Optimal Way to Implement an 
ERP? 


There are two options that an organization can choose from when implementing 
an ERP. The first option (the option the Army, DLA, Marine Corps, and Air Force 
elected) is the “design first then implement” approach. This is the option corporations 
choose when they have already made the decision that a switch is definitely going to be 
made to an ERP. It is a faster path toward implementation because there is no test of the 
ERP in a sector of the organization. The “design first then implement” approach follows 
the ERP life cycle outlined in Chapter II which starts with product evaluation and 
precedes into implementation phase I and phase II. 

The other option an organization can choose is the prototyping approach (the 
Navy’s choice) which involves one or two pilot projects to test the organization redesign 
that an ERP requires prior to translating the redesign across the entire organization. 
Using the prototyping approach also starts with product evaluation but in the 
implementation phase, only a portion of the ERP is implemented such as the operations 
planning function. If that function is deemed a success, then the organization will 
proceed to implement additional functionality. 

With either methodology, the organization that will be most successful is the one 
that establishes a “strong man” for the project who comes from the highest level of the 
organization so that he can resolve the conflicts that arise between the core team 
members representing the different functional areas. A characteristic that the “strong 
man” must possess is they have to be open to the business processes that are resident 
within the ERP so they can ensure their organization avoids the number one ERP pitfall: 
overcustomization. 

3. How Does an ERP Integrate Business Processes that are Not Part of 
the Standardized Software Suite? 

The “strong man” has to be open to the business processes of the ERP primarily 
so they can make determinations about the necessity of old business processes. They also 
have to be open to the business processes of the ERP so they can instruct their team how 
to handle the situations where the ERP does business differently than the organization. 
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When this type of situation is encountered, as was discussed in Chapter II, the RICE 
acronym is used. Again, RICE stands for reports, interfaces, conversions, enhancements 
and it is the order that solutions are sought to cover the gaps between the functionality of 
the legacy systems and the ERP. The first option, reports will be used when the 
information that was produced from a legacy system can be generated as a report out the 
ERP. Interfacing to a system that has the essential capability is the next solution. The 
third option is to convert the data in the old system into a form that the logic in the ERP 
can understand. Einally, an enhancement of the ERP is the last option that should be used 
because it is a change to the core of the ERP to the way business is conducted by the 
organization. Despite the confusing vocabulary that suggests an enhancement is a 
positive action, it is not! If an organization has to resort to an enhancement, it generally 
means that the organization is clinging to the old way of doing things and is intending to 
negate the benefits of employing an ERP. Every effort should be made to prevent using 
an enhancement as a viable option [39]. 

Enhancements are different than an improvement that adds functionality to the 
ERP. A good example of an improvement is a custody tracking function that is needed 
for military customers. Adding this functionality to the core ERP because it does not 
exist is an improvement that can be sold to other customers in the military product line. 
This is added functionality. Contrarily, an enhancement takes functionality out of the 
core software and replaces it with software code so that the organization does not have to 
change the way it does business. 

4. What are Experiences and Plans of the Individual ERP Programs? 

The individual experience and plans of each DOD ERP program to date forms the 
content of Chapter III. After wasting a billion dollars on the four pilot projects, the Navy 
is attempting to converge the four pilots at a cost of another $800 million into a single 
ERP to manage the Navy’s wholesale supply functions. The Navy is estimating that full 
operational capability (EOC) will be achieved in the Spring of 2013. 

To meet the needs of the Army’s wholesale supply functions, the Eogistics 
Modernization Program (EMP) went live in July 2003 and was certified PPMIA 
compliant in May 2007 [87]. Currently, the Army is working on replacing the thirteen 
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legacy systems that manage the retail level of Army logistics with the GCSS-Army ERP. 
Initial operational capability is predicted to occur in October 2010 with an FOC date of 
January 2014 [54]. If the Army completes the GCSS initiative and merges the retail 
system with the LMP, the vision of a Single Army Logistics Enterprise (SALE) will be a 
reality. “The result of implementing the SALE is a merger of warfighter and business 
systems into a single, harmonious environment from the manufacturer to the foxhole, 
which is aligned with joint requirements” [54]. 

Once the Navy and the Army started their ERP programs in the late 1990s, DLA 
was faced with the possibility that the Agency’s position as the DODs intermediary 
distributor would cease to be relevant if the individual services had the capacity to 
connect their ERPs directly to vendors and streamline the supply chain. In response, 
DLA started the Business System Modernization (BSM) program in 2000 and achieved 
FOC in late 2006. Having achieved FOC, DLA is working on extending the enterprise 
with some of the most promising initiatives in the DOD including the Distribution 
Planning and Management System (DPMS), the Integrated Data Environment (IDE), the 
National Inventory Management Strategy (NIMS), the Global Stock Positioning (GSP) 
system, and the Product Data Management Initiative (PDMI). Each of these initiatives is 
discussed in detail in Chapter III. When these projects are complete, DLA will be the 
central repository for all the logistics data for the DOD covering in-transit shipping 
visibility, unit location data, material stock locations, equipment technical data, and most 
importantly, the NIMS initiative will make DLA the owner and manager of all 
consumable material for the DOD. 

By waiting on the outcomes of the initial ERP projects, the Marine Corps and the 
Air Force have been able to capitalize on the lessons learned. The plans developed by the 
two service components demonstrate an understanding that there is no need to develop 
separate ERP systems that perform the same functions. Product line software 
architectures like those of an ERP present an opportunity to use the exact same system 
with each having few additional improvements to handle the peculiarities of each service. 
Thus, the Marine Corps and the Air Force are essentially pooling their resources to get 
the best single ERP possible. FOC for GCSS-Marine Corps is anticipated in 2015 and 

the Air Force has set an ambitious FOC date of 2013 for the ECSS system. 
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5. What Are the Lessons Learned to Date that Will Assist the DOD in 
Achieving the Joint Vision for the ERP Programs? 

Having separate ERPs within the separate services performing the same functions 
is duplicative. It would be more beneficial if Figure 5.2 read U.S. military, British 
military, German military for efficiency and cost but the figure accurately portrays 
reality. This by no means suggests that it was a bad idea for the DOD to use ERPs for 
business process transformation. The benefits of software product lines and the 
utilization of a proven software architecture are good justification to support the DOD’s 
decision to go with ERP systems. Moreover, the DOD’s character as a mechanistic 
organization discussed in Chapter IV along with the dismal record the Department has 
with custom software (90% failure rate) rules out any notion that custom software should 
have been used. Custom software may be the answer for other systems in the DOD but 
that is beyond the scope of this thesis. In the logistics arena, the DOD looked for 
industry “best practices” and that equated to ERP [94]. 

Besides the Navy’s problems with the first two pitfalls of an ERP 
(overcustomization and lack of top management commitment) and the Army’s problem 
with pitfall number three (resistance to change/lack of buy-in by the AMC programmers), 
a bigger problem has arisen as a result of the framework surrounding the programs as a 
whole. By having these separate ERPs with overlapping functions, the DOD has come to 
the realization that these systems are going to have to be integrated to achieve “focused 
logistics.” In order to guarantee that the separate services work toward the vision of an 
integrated supply chain, the “Deputy Secretary of Defense, Gordon England directed the 
establishment of the Defense Business Transformation Agency (BTA) in a memorandum 
effective October 7, 2005” [95]. Despite being about nine years late, the BTA is the best 
solution for the integration problem. The BTA is the overarching agency responsible for 
establishing the architecture and data standards that the separate ERPs are to adhere to in 
order to ease the integration effort. As was stated in Chapter IV, in industry it has been 
proven that integrating ERPs of separate organizations is a much easier task than 
integrating legacy stovepiped systems. The task is even easier if there is a framework in 
place that specifies the data structure of the components that are going to fit together in 
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the framework. An institution to set up a framework and lay down the standards is the 
critical role that has been missing from the DOD ERP programs and it is finally being 
fulfilled by the BTA. 


C. RECOMMENDATIONS 

It is going to be more problematic for the separate programs to adhere to the BTA 
standards because the programs are so far along in their progress. Had the BTA been 
established when the programs got started it is unlikely that the structure of the ERP 
projects would resemble the current situation. It is probable that a central managing 
agency would have acknowledged the fact that at the same time the DEA first explored 
ERP, the Navy and the Army were also looking for a better IT system for the same 
logistics process. 



Eigure 5.3. The Eogistics Process (Prom: [91]) 

Chapter III emphasizes the fact that the Army’s EMP and the Navy’s ERP programs 
started to buy new systems for the acquisition and in-service support of weapons systems. 
At the point in the late 1990s when the first three programs got underway, had anyone 
looked at the DOD as the enterprise from the top down, they would have realized that the 
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plan to buy three separate systems to aid with distribution, sustainment and disposition 
was a path to three more “stovepiped” systems. 

It is here where the DOD missed the opportunity to have an optimal ERP 
implementation. All the service components acquire major weapons systems in the same 
way. Therefore, there is only a need for one system to perform acquisitions. 
Additionally, all military equipment is maintained in the same way so there is no for 
separate systems to perform that function either. Therefore, it is recommended that for 
the supply chain management operation, after major weapons systems are acquired, the 
best process would be for the services to hand-off responsibility for in-service support 
(meaning supply) and disposition to the DLA. That is the difference between DLA as a 
distributor and a distributor in the commercial sector. When customers in the commercial 
sector order items from a distributor such as Amazon.com, the customer isn’t running 
their own ERP. They simply link into the distributors system and order the material that 
is needed. As depicted in Eigure 3.10, the separate service components are the customers 
of the DEA who is functioning as a distributor. Currently, DEA only distributes 
consumable material. However, there is no reason why they could not handle repairable 
components as well. While it would be ideal if the separate service components used the 
same acquisition system, it is not absolutely necessary. The greatest potential to improve 
the ERP programs is to have the service components keep the acquisition systems that 
each is acquiring in the separate ERP projects but, in-service support and disposal should 
be the responsibility of the DEA. Presently, the NIMS initiative is guiding the DOD in 
this direction for consumable material. A repairable material initiative should be started 
so that DEA handles the life cycle of all material from the time it comes in-service 
through disposal. 

D. FUTURE RESEARCH POSSIBILITIES 

This research focused on analyzing the lessons learned from industry that will 
help the DOD’s ERPs be successful. Additionally, a comparison of the separate service 
component’s ERP strategies was conducted to benchmark the programs against each 
other and against industry best practices to provide the DOD a reference to help the 
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projects in the future. Some additional research possibilities generated by this thesis but 
not addressed in the document include: 

• How does an automatic identification method such as radio frequency 
identification (RFID) interact with ERPs and how will the combination of 
the two capabilities improve DOD supply chain management practices? 

• What impact will the ERPs have on the DOD manpower structure? 

• Given that DEA acts as an intermediary distributor for consumable 
material, what changes would have to be made within the DOD to make 
DEA responsible for all material, repairable and consumable? 

• What are the metrics being used to evaluate how well the ERPs are 
performing as compared to the legacy systems they are intended to 
replace? 


106 



LIST OF REFERENCES 


[1] United States Government Accountability Officer, “Financial management, 
improved financial systems are key to FFMIA compliance,” Washington D.C., 
Rep. GAO-05-20, October 2004. 

[2] E. Oxendine and D. M. Hoffman, “Enterprise Resource Planning (ERP): A case 
study of Space and Naval Warfare Systems Center San Diego’s Project Cabrillo,” 
M.S. Thesis, Naval Postgraduate School, Monterey, California, 2002. 

[3] W. Eucyshyn, K. Snider, and R. Maly, “The Army seeks a world class logistics 
modernization program,” Naval Postgraduate School, Monterey, California, 
Acquisition Research Sponsored Rep., June 2004. 

[4] “Enterprise systems,” class notes for IS 4031, Department of Information 
Sciences, Naval Postgraduate School, Pall 2006. 

[5] T. Hauser, J. Graham, P. Koerner, and P. Davis, “A fully integrated global 
strategic supply network- A critical enabler of DoD transformation,” National 
Defense University, Washington D.C., Strategic Supply Industry Study, 2004. 

[6] J. Butler, “A history of information technology and systems,” July 1998, 
http://www.tcf.ua.edu/AZ/ITHistoryOutline.htm, Accessed August 2006. 

[7] S. Vandana, “Pederal IT is stable despite changes,” April 2003, 
http://www.gcn.com/print/22_8/21733-l.html. Accessed August 2006. 

[8] T. P. Wallace, ERP: Making It Happen, The Implementer’s Guide to Success with 
Enterprise Resource Planning. New York: Wiley, 2001. 

[9] S. Hamilton, Maximizing Your ERP System, A Practical Guiderfor Mangers. 

New York: McGraw-Hill, 2006. 

[10] D. N. Burt, D. W. Dobler, and S. E. Starling, World Class Supply Management, 
The Key to Supply Chain Management. New York: McGraw-Hill, 2003. 

[11] R. B. Chase, R. P. Jacobs, N. J. Aquilano, and A. K. Nitin, Operations 
Management for Competitive Advantage. New York: Tata McGraw-Hill, 2006. 

[12] J. E. Beasley, “OR-Notes,” August 2006, 
http://people.brunel.ac.uk/~mastjjb/jeb/or/mrp.html. Accessed September 2006. 

[13] S. Wheller, “ERP II demystified,” June 2004, http://www.vendor- 
showcase.eom/Research/ResearchHighlights/Erp/2004/06/research_notes/TU_ER 
_XSW_06_18_04_l.asp, Accessed September 2006. 


107 



[14] P. Finger, “Intelligent enterprise: prime time for real time,” October 2004, 
http://www.intelligententerprise.com/print_article.jhtml?articleID=159907840, 
Accessed September 2006. 

[15] T. H. Davenport, Mission Critical-Realizing the Promise of Enterprise Systems. 
Boston: Harvard Business School Press, 2000. 

[16] Exact Software, “ERP II: making ERP deliver on its promise to the enterprise,” 
November 2005, http://i.i.com.com/cnwk. Id/html/itp/MAS 1600_ERPII_low.pdf, 
Accessed September 2006. 

[17] C. Koch, “The ABCs of ERP,” January 2006, 
http://www.cio.com/research/erp/edit/erpbasics.html. Accessed September 2006. 

[18] R. Palaniswamy and T. Prank, “Enhancing manufacturing performance with ERP 
systems,” Information Systems Management vol. 17, iss. 3, pp. 43-55, 2000. 

[19] M. Singer, “Oracle set to conclude merger,” January 2005, 
http://www.internetnews.com/bus-news/article.php/3455811, Accessed November 
2006. 

[20] C. J. Ward, “ERP: integrating and extending the enterprise,” Spring 2006, 
www.thepublicmanager.org. Accessed November 2006. 

[21] General Electric, “Performance summary,” December 2006, 
http://www.ge.eom/ar2006/ltr_performance.htm. Accessed January 2007. 

[22] A. Pisher, “America’s most admired companies,” Fortune Magazine, vol. 153, pp. 
65-76, March 2006. 

[23] E. Weinman, “The United States Mint: A model for government e-business,” 
October, 2000, http://www.netcaucus.org/books/egov2001/pdf/CaseStud.pdf, 
Accessed Pebruary 2007. 

[24] U.S. Department of Energy, “U.S. Strategic Petroleum Reserve,”January 2007, 
http://www.fe.doe.gov/programs/reserves/index.html. Accessed Pebruary 2007. 

[25] SAP Information, “Strategic Petroleum Reserve selects SAP solution,” September 

2000, 

http://www.sap.info/index.php4?ACTION=noframe&url=http://www.sap.info/pu 
blic/INT/int/index/PrintEdition-78313c67 8e lecc378-int/0/comvArticleContainer- 
198983c63c52c8930d, Accessed Pebruary 2007. 

[26] IT Cortex, “Pailure rate: statistics over IT projects failure rate,” March 2007, 
http://www.it-cortex.com/Stat_Pailure_Rate.htm, Accessed March 2007. 


108 



[27] S. Chang, G. Gable, E. Smythe, and G. Trimbell, “A Delphi examination of 
public sector ERP implementation issues,” in Proceedings of the Twenty First 
International Conference on Information Systems, 2000, pp. 494-500. 

[28] R. G. Eigus, “The 12 cardinal sins of ERP implementation,” January 2004, 
http://rockfordconsulting.com/12sinart.htm. Accessed March 2007. 

[29] B. Zhang, “Causes of ERP failures,” March 2005, 
http://www.webpronews.eom/topnews/2005/03/29/causes-of-erp-failures. 
Accessed March 2007. 

[30] C. Koch, “Hershey’s bittersweet lesson,” November 2002, 
http://www.cio.com/archive/111502/tl_hershey.html. Accessed March 2007. 

[31] B. Worthen, “Nestle’s ERP odyssey,” CIO Magazine, pp. 62-70, May 2002. 

[32] A. Ragowski and T. M. Somers, “Special section: Enterprise Resource Planning,” 
Journal of Management Information Systems, vol. 19, pp. 11-16, Summer 2002. 

[33] M. E. Markus, “Technochange management: using IT to drive organizational 
change,” Journal of Information Technology, vol. 19, pp. 4-20, March 2004. 

[34] T. D. Tick and M. A. Peiperl, Managing Change: Cases and Concepts 2”“^ Edition. 
New York: Mc-Graw Hill College, 2002. 

[35] “Business process reengineering best practices,” class notes for IS 4220, 
Department of Information Sciences, Naval Postgraduate School, Pall 2006. 

[36] “Overview of business process reengineering,” class notes for IS 4220, 
Department of Information Sciences, Naval Postgraduate School, Winter 2007. 

[37] M. Schrage, “The key to innovation: overcoming resistance,” CIO Magazine, vol. 
19, p. 34, October 2005. 

[38] “Software project management,” class notes for IS 4300, Department of 
Information Sciences, Naval Postgraduate School, Spring 2007. 

[39] R. Robinson (private communication), 2006. 

[40] A. Klee, “The ERP life cycle: from birth to death to life again,” March 2007, 
http://hosteddocs.ittoolbox.eom/AK051305.pdf, Accessed April 2007. 

[41] V. Kumar, B. Maheshwari, and U. Kumar, “Enterprise Resource Planning 
systems adoption process: A survey of Canadian organizations,” International 
Journal of Production Research, vol. 43, pp. 3952-3982, October 2005. 


109 



[42] United States Department of Defense, “The 1997 Quadrennial Defense Review,” 
Office of The Secretary of Defense, Washington, D.C., May 1997. 

[43] Chairman of the Joint Chiefs of Staff, Joint Vision 2010. Washington D.C.: Office 
of the Chairmam, 1997. 

[44] U.S. Secretary of Defense, Defense Reform Initiative. Washington D.C.: Office of 
The Secretary, 1997. 

[45] United States Government Accountability Officer, “DOD business systems 
modernization. Navy ERP adherence to best business practices critical to avoid 
past failures,” Washington D.C., Rep. GAO-05-858, September 2005. 

[46] Microsoft Corporation, “Choosing the right partner for your ERP project,” 
http://www.microsoft.com/canada/midsizebusiness/businessvalue/local/rightpartn 
er.mspx. Accessed April 2007. 

[47] Enterprise Integration Inc., “The Navy ERP architecture,” Office of Enterprise 
Integration Inc., Washington, D.C., White Paper, 2004. 

[48] EMP Special Project Team, “The business case: wholesale logistics 
modernization program,” U.S. Army CECOM, Eort Belvoir, Virginia, Business 
Case, 2004. 

[49] J. Gamsler, “Moving toward market-based government: the changing role of 
government as the provider,” Center for Public Policy and Private Enterprise and 
the IBM Endowment for the Business of Government, Washington, D.C., Rep., 
2003. 

[50] B. Eriel, “Army outsourcing plan lead to employee exodus,” October 1999, 
http://www.govexec.com/. Accessed April 2007 

[51] United States Government Accountability Officer, “DOD competitive sourcing: 
plan needed to mitigate risks in Army logistics modernization program,” 
Washington D.C., Rep. GAO-NSIAD-00-19, October 1999. 

[52] E. Duerinck, “Use of due diligence in the wholesale logistics modernization 
program: maximizing free and open communication between industry and 
government,” Program Management, vol. 29, pp. 60-62, July-August 2000. 

[53] D. Caterinicchia, “Army logistics marches ahead,”November 2002, 
http://www.fcw.eom/fcw/articles/2002/l 118/pol-army-l 1-18-02.asp. Accessed 
May 2007. 


no 



[54] Business Transformation Agency, “GCSS-Army dashboard,” March 2007, 
http://www.defenselink.mil/dbt/products/March_2007_BEA_ETP/etp/App_E/Qua 
dCharts/GCSS-Army_Chart.html, Accessed May 2007. 

[55] U.S. Army, “SAEE white paper,” 
http://www.hqda.army.mil/logweb/integrated_logistics_environment.pdf. 
Accessed May 2007. 

[56] United States Government Accountability Officer, “Defense inventory: several 
actions are needed to further DEA’s efforts to mitigate shortages of critical parts,” 
Washington D.C., Rep. GAO-03-709, August 2003. 

[57] The Defense Eogistics Agency, Transformation Roadmap: Transformation in 
Support of the Future Force. Eort Belvoir, Virginia, Defense Eogistics Agency, 
2005. 

[58] United States Government Accountability Officer, “Information technology: 
inconsistent software acquisition processes at the Defense Eogistics Agency 
increase project risks,” Washington D.C., Rep. GAO-02-9, January 2002. 

[59] J. Kimberly, “Business system modernization: delivering 2U‘ century logistics,” 
October 2005, http://www.dla.mil/J-6/bsm/library/briefing/0102cienceboard.ppt, 
Accessed June 2007. 

[60] Preferred Systems Solutions Inc., “PSS and Accenture score big win!” December 
1999 http://www.pssfed.com/Archive.aspx?Year= 1999&Month= 12, Accessed 
June 2007. 

[61] Headquarters United States Marine Corps, “Eogistics Modernization Operations,” 
Headquarters United States Marine Corps, Washington, D.C., Solution Initiating 
Directive, 2005. 

[62] United States Marine Corps, “Official Marine Corps Site for EOGMOD,” May 
2007, https://logmod.hqmc.usmc.mil/Initiatives_RoS.htm, Accessed June 2007. 

[63] R. E. Delarm, and R. Eckert, EtCol USMC (Ret), “GCSS-MC: Ready to Put the 
Pieces Together,” Marine Corps Gazette, vol. 89, pp. 20-22, August 2005. 

[64] R. E. Dealarm, “Advanced planning briefing to industry 2006,” April 2006, 
http://www.dtic.mil/ndia/2006mcsc_apbi/agenda.pdf. Accessed June 2007. 

[65] The White House Office of Management and Budget (0MB) “Report on 
Information Technology Spending for the Eederal Government for Eiscal Years 
2003, 2004, and 2005 Spreadsheet,” January 2006, 

http://www.whitehouse.gOv/omb/egov/documents/BY2005_itspending.xls, 
Accessed June 2007. 


Ill 



[66] Headquarters United States Air Force, “Operational requirements document 
(ORD) For global combat support system - Air Force (GCSS-AF)”, Headquarters 
United States Air Force Office of The Chief Information Officer ,Washington, 
D.C., Operational Requirements Document, 2001. 

[67] Material Systems Group, United States Air Force, Expeditionary Combat Support 
System (ECSS) Program Pre-Solicitation Notice/Notification of Program 
Direction., Wright-Patterson AFB, Ohio, United States Air Force Material 
Systems Group, 2004. 

[68] S. Cowley, “Oracle Wins $88.5M Air Force Contract,” October 2005, 
http://www.computerworld.com/industrytopics/defense/story70,10801,105703,00. 
html. Accessed July 2007. 

[69] M. Morales, “ESC Awards $627.8 Million ECSS System Integrator Task Order,” 
September 2006, 

http://www.hanscom.af.mil/mediacenter/archive/story.asp?id=I23036049, 
Accessed July 2007. 

[70] Business Transformation Agency, “ECSS Dashboard,” March 2007, 
http://www.defenselink.mil/dbt/products/March_2007_BEA_ETP/etp/App_E/Qua 
dCharts/ECSS_Chart.html, Accessed July 2007. 

[71] Chairman of the Joint Chiefs of Staff, Joint Vision 2020. Washington D.C.: Office 
of the Chairmam, 2000. 

[72] V. Clark, Admiral USN (Ret), “Sea power 21: projecting decisive joint 
capabilities,” U.S. Naval Institute Proceedings, vol. 128, pp. 32-41, October 
2002. 

[73] C. Moore Jr., Vice Admiral USN and E. Hanlon Jr., Eieutenant General USMC, 
“Sea basing: operational independence for a new century,” January 2003, 
http://www.military.eom/NewContent/0,13190,NI_Sea_0103,00.html. Accessed 
July 2007 

[74] J. J. Klein, Eieutenant Commander USN, and R. Morales, Major USA, “Sea 
basing isn’t just about the sea,” U.S. Naval Institute Proceedings, vol. 130, p. 32, 
January 2004. 

[75] W. Matthews, “U.S. Eawmakers Want a Shipbuilding Cost Czar,” May 2006, 
http://www.defensenews.com/story.php?E=1748997&C=america, Accessed July 
2007. 

[76] J. P. Kotter, “Eeading change: why transformation efforts fail,” Harvard Business 
Review; March-April 1995. 


112 



[77] P. Candreva, Commander USN (Ret) (private communication), 2007. 

[78] D. Robey, J. W. Ross, and M. Boudreau, Learning to Implement Enterprise 
Systems: An Exploratory Study of the Dialectics of Change. Cambridge, M.A.: 
MIT Center for Information Systems Research, 2000. 

[79] D. Allen, T. Kem, and M. Haverhand, “ERP critical success factors: an 
exploration of the contextual factors in public sector institutions,” in Proceedings 
of the 3Annual Hawaii International Conference of System Sciences, 2002, pp. 
3062-3071. 

[80] M. Nissen and F. Barrett, “Changing major acquisition organizations to adopt the 
best loci of knowledge, responsibility and decision rights,” presented at 
Proceedings of the Third Annual Acquisition Research Symposium, Monterey, 
California, 2006. 

[81] Business Transformation Agency, “Navy ERP Dashboard,” March 2007, 
http://www.defenselink.mil/dbt/products/March_2007_BEA_ETP/etp/App_E/Qua 
dCharts/Navy_ERP_Chart.html, Accessed July 2007. 

[82] Navy ERP Office, “Navy ERP FAQs,” 
http://www.erp.navy.mil/Navy%20ERP%20Frequently%20Asked%20Questions. 
pdf. Accessed July 2007. 

[83] J. P. Kotter and E. A. Schlesinger, “Choosing strategies for change”. Harvard 
Business Review, vol. 57, pp. 106-114, 1979. 

[84] J. P. Kotter, Leading Change. Cambridge, Massachusetts: Harvard Business 
School Press, 1996. 

[85] C. A. Thomas, “Investigating the Department of Defense’s implementation of 
passive radio frequency identification,” presented at Proceedings of the Third 
Annual Acquisition Research Symposium, Monterey, California, 2006. 

[86] R. Pascale, M. Millerman, and E. Gioja, “Changing the way we change”. Harvard 
Business Review, vol. 75, pp. 126-139, November-December, 1997. 

[87] Business Transformation Agency, “EMP dashboard,” March 2007, 
http://www.defenselink.mil/dbt/products/March_2007_BEA_ETP/etp/App_E/Qua 
dCharts/EMP_Chart.html, Accessed July 2007. 

[88] D. S. Alberts, J. J. Gartska, and F. P. Stein, Network Centric Warfare: Developing 

and Leveraging Information Superiority Edition (RevAed). Washington, D.C.: 

DoD C4ISR Cooperative Research Program, 2000. 


113 



[89] R. L. Kelly, Lieutenant General USMC, “Logistics Modernization: Lethality and 
Effectiveness,” August 2005, 

http://hqinetOOLhqmc.usmc.mil/i&l/v2/L/Left/CurrentIssues/Kelly.pdf. Accessed 
July 2007. 

[90] C. R. Mueller First Lieutenant USAF, “Joining the Department of Defense 
Enterprise Resource Planning team: The Air Force’s role in the enterprise,” M.S. 
thesis. Air Force Institute of Technology, Wright-Patterson AFB, Ohio, 2003. 

[91] U.S. Marine Corps, Logistics. Marine Corps Doctrinal Publication 4, 1997. 

[92] “Software product lines,” class notes for IS 4182, Department of Information 
Sciences, Naval Postgraduate School, Summer 2007. 

[93] I. Gorton, Essential Software Architecture. New York: Springer, 2006. 

[94] R. Rosenthal, “The fourth “R”: Navy ERP,” The Navy Supply Corps Newsletter, 
vol. 68, pp. 9-10, May/June 2005. 

[95] Business Transformation Agency, “BTA: Business Transformation Agency 
FAQs” Available [online] http://www.defenselink.mil/bta/about/faqs.html. 
Accessed July 2007. 


114 



INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 

Ft. Belvoir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 

3. Marine Corps Representative 
Naval Postgraduate School 
Monterey, California 

4. Director, Training and Education, MCCDC, Code C46 
Quantico, Virginia 

5. Director, Marine Corps Research Center, MCCDC, Code C40RC 
Quantico, Virginia 

6. Marine Corps Tactical Systems Support Activity (Attn: Operations Officer) 
Camp Pendleton, California 

7. Head, Information Operations and Space Integration Branch, PLI/PP&O/HQMC, 
Washington, DC 


115 



